not needed yet, but returning a resource from the exception handling
path that has ownership of a handle is currently not well-supported.
we could also add a default constructor to Handle, but then we would
also need to change the pool reference to a pointer. eventually that
should be done since now resources can be swapped between pools with
clever moves, but since that's not a problem yet we won't do it now.
Change-Id: I26eb06581f7be34569e9e67a33da736128d167af
the duplication of exception handling was added without justification,
so we can only assume that it was done like this because Finally could
not throw exceptions safely. since this has now been rectified we will
deduplicate this handler code again.
Change-Id: I40721f3378c0fd9f34e2914a16d383f6e2713b40
this is supposed to act like a finally block does in other languages. a
finally block should be able to throw exceptions of its own rather than
just crashing the entire program when it throws it own exceptions. even
in the rare case of a finally throwing an unexpected exception it might
be better to report the exception from Finally instead of the original,
at least that can keep our program running instead of letting it crash.
Change-Id: Id42011e46b1df369152b4564938c0e93fa1acf32
usage of this flag previously kept connections open much longer than
necessary, and at the same time obscured that a connection was being
dropped when it *was* set. new variable names clarify this somewhat.
Change-Id: I11f6f08f37a5e4dc04ea6c6036ea589154b121c6
it was used incorrectly (not swapped on handle move), only used in one
place (that is now handled with exception handling detection in Handle
itself), and if ever reintroduced should be replaced with a different,
more understandable mechanism (like an explicit dropAsInvalid method).
Change-Id: Ie3e5d5cfa81d335429cb2ee5c3ad85c74a9df17b
this was never actually used, and bad design in the first place—why
should a bad resource be put back into the idle pool? just drop it.
Change-Id: Idab8774bee19dadae0209d404c4fb86dd4aeba1e
if a scope owning a resource does not gracefully drop that resource
while handling exceptions from deeper down the call stack we should
assume the resource is invalid state and drop it. currently it *is*
true that such cases do not cause resources to be freed, but thanks
to validator misuses this has so far not caused any larger problem.
Change-Id: Ie4f91bcd60a64d05c5ff9d22cc97954816d13b97
Perl has an env hook[1]. Passing the paths manually without putting them
in buildInputs is harder to understand, plays less nicely with dev
shells, and is less build-generic.
Produced identical output on my x86_64-linux machine, and on my
aarch64-darwin machine was identical save for the derivation output path
which gets embedded into the .dylib Mach-O.
Change-Id: Ib313caa5a6f0b0e3154ce6f05379033920d0d290
this notably does *not* install the `nix3-manpages` manpage the old
system generated, mostly because that page was empty and just a bug
with a coat of documentation paint.
Change-Id: I7a4248a72e7bb5e0cc925a6311a33b6b72589569
we'll want to use these for the meson builds, and probably eventually
rewrite them in something that isn't plain shell. diffoscope confirms
that out/share and doc/share are equal before and after these changes
Change-Id: I49aa418fc8615cad86d67328e08c28a7405ec952
The big ones here are `trim-trailing-whitespace` and `end-of-file-fixer`
(which makes sure that every file ends with exactly one newline
character).
Change-Id: Idca73b640883188f068f9903e013cf0d82aa1123
This does involve making a large number of destructors able to throw,
because we had to change it high in the class hierarchy. Oh well.
Change-Id: Ib62d3d6895b755f20322bb8acc9bf43daf0174b2
This has not yet had all the warnings Obliterated, but it is a start and
is not *super* far away from being able to run the current configuration
in CI, which will catch some limited number of mistakes.
I tried the meson clang-tidy target and it seems to fail to find flags
for several files, which seems broken. Unsure what is up with that, but
we can use run-clang-tidy or other tooling instead.
We have an extremely annoying situation with the lexer table, which
means that the lexer probably must be moved to another directory with
its own .clang-tidy file to disable the lints in it, *or* write scuffed
code that prepends a disable comment to the top of the generated file.
None of the comment-based lint disabling features work since yacc dumps
a bunch of non compliant code at the top of the file before anything the
user can control.
Change-Id: I1d2aa6ec32deb1db1fbd581127334db1b972323c
* some things that can throw are marked noexcept
yet the linter seems to think not. Maybe they can't throw in practice.
I would rather not have the UB possibility in pretty obvious cold
paths.
* various default-case-missing complaints
* a fair pile of casts from integer to character, which are in fact
deliberate.
* an instance of <https://clang.llvm.org/extra/clang-tidy/checks/bugprone/move-forwarding-reference.html>
* bugprone-not-null-terminated-result on handing a string to curl in
chunks of bytes. our usage is fine.
* reassigning a unique_ptr by CRIMES instead of using release(), then
using release() and ignoring the result. wild. let's use release() for
its intended purpose.
Change-Id: Ic3e7affef12383576213a8a7c8145c27e662513d
We got confused what formals did and had to briefly figure it out. We
should just have docs, so these are some.
Change-Id: If3e794a401e69d022785cbfa0b0c2e2284f41f58
Since we don't have a ./configure checked in, it makes no sense to keep
any of these scripts since people are already going to be running
autoreconf anyway.
Plus they will be completely deletable when meson shows up.
This fixes `autoreconfPhase` causing git diffs.
Change-Id: Ibb2aee422c562a23faadfdedb55b5c18c41a9420
the autoconf build system defaults to /nix/var, not /nix/var/nix. the
latter is only used in libstore, so we'll move the extra segment there.
Change-Id: Idfbc988ee302355982abdcd51d6d7b5d5d661c0d
Without this, the Meson setup won't bail out if nlohmann_json is
missing, leading to subpar DX (and maybe worse, but I'm not entirely
sure).
Change-Id: I5913111060226b540dcf003257c99a08e84da0de
one headers (args/root.hh) was simply missing, and the generated headers
were not installed. not all of them *should* be installed either, only a
select few (and sadly this needs a custom target for each one, it seems)
Change-Id: I37b25517895d0e5e521abc1202fa65624de57ed1
sometimes these fail with timeouts on loaded machines. let's up the
timeouts until we can pull the tests apart to more reasonable sizes
Change-Id: I2dfff2183cc1f3ff5e6107f43748ac046fe00d05
- Enable parallel builds by default (and allow using environment
variables to override `make` variables)
- Hopefully we can get rid of this once we have Meson
- Set `GTEST_BRIEF=1`
- This only shows failed tests, instead of listing every test on its
own line.
```
$ GTEST_BRIEF=1 make check
[==========] 328 tests from 15 test suites ran. (37 ms total)
[ PASSED ] 328 tests.
```
Change-Id: Id8103a8f24a9681be2be87e1b4df6fd5fdd7e4fd
Functional tests can be run with
`meson test -C build --suite installcheck`.
Notably, functional tests must be run *after* running `meson install`
(Lix's derivation runs the installcheck suite in installCheckPhase so it
does this correctly), due to some quirks between Meson and the testing
system.
As far as I can tell the functional tests are meant to be run after
installing anyway, but unfortunately I can't transparently make
`meson test --suite installcheck` depend on the install targets.
The script that runs the functional tests, meson/run-test.py, checks
that `meson install` has happened and fails fast with a (hopefully)
helpful error message if any of the functional tests are run before
installing.
TODO: this change needs reflection in developer documentation
Change-Id: I8dcb5fdfc0b6cb17580973d24ad930abd57018f6
This was achieved by running maintainers/buildtime_report.sh on the
build directory of a meson build, then asking "why the heck is json
eating our build times", and strategically moving the json using bits
out of widely included headers.
It turns out that putting literally any metrics whatsoever into the
build had immediate and predictable results.
Results are 1382.5s frontend time -> 1175.4s frontend time, back end
time approximately invariant.
Related: lix-project/lix#159
Change-Id: I7edea95c8536203325c8bb4dae5f32d727a21b2d
I didn't enable this by default for clang due to making the build time
10% worse or so. Unfortunate, but tbh devs for whom 10% of build time is
not *that* bad should probably simply enable this.
Change-Id: I8d1e5b6f3f76c649a4e2f115f534f7f97cee46e6
eldritch horrors
jade
Rebecca Turner
Qyriad
Jade Lovelace
Winter Cute
raito