It is a little bit scuffed, but it seems to produce correct results. We
can run it at a later date when we want to explode every in-flight
commit in existence and then need to filter-branch them.
Fixes: lix-project/lix#188
Change-Id: Id97e4651f78804a941d941df02c7c1b21ce453b6
This is terrible UX, and frankly an eval failure should be a cache
invalidation anyway.
This removes the CachedEvalError type entirely.
Fixes#223.
Change-Id: I91f8003eabd0ea45003024e96d1de3c7ae8e49d8
Commit c21d11ac0 "docs: replace sed invocation with an mdbook
preprocessor for @docroot@" added a direct build dependency on Python.
This has been accidentally working so far because Python is already a
*transitive* dependency of Lix's derivation.
Change-Id: I32d6b4f2665dbbfad7014613457dd58aa4ec73da
* changes:
Revert "libutil: drop Pool resources on exceptional free"
Revert "libutil: remove Pool::Handle::bad"
Revert "libstore: remove one Resource::good flag"
Revert "libstore: using throwing finally in withFramedSink"
Revert "libutil: allow graceful dropping of Pool::Handle"
Revert "libutil: drop Fs{Source,Sink}::good"
libutil: guard Finally against invalid exception throws
- Use a recursive descent parser so that it's easy to extend.
- Add `@args` to enable customizing command-line arguments
- Add `@should-start` to enable `nix repl` tests that error before
entering the REPL
- Make sure to read all stdout output before comparing. This catches
some extra output we were tossing out before!
Change-Id: I5522555df4c313024ab15cd10f9f04e7293bda3a
This reverts commit 491caad6f6.
this is not actually legal for nix! throwing exceptions in destructors
is fine, but the way nix is set up we'll end up throwing the exception
we received from the remote *twice* in some cases, and such cases will
cause an immediate terminate without active exception.
Change-Id: I74c46b9f26fd791086e4193ec60eb1deb9a5bb2a
throwing exceptions is fine, but throwing exceptions during exception
handling is hard enough to do correctly that we should just forbid it
entirely out of an overabundance of caution. in cases where terminate
is the correct answer the users of Finally must call it manually now.
Change-Id: Ia51a2cb4a0638500550bfabc89cf01a6d8098983
These were mistakenly labeled `eval-fail-*`.
Note that the `lang.sh` runner passes `parse-fail-*` tests on stdin, so
filenames are removed from error messages.
Change-Id: I7f3a0d78b6cfa87af29aaa1b7af19d5a57fd4ade
We're not entirely clear on why the links preprocessor has to be done
*before* rather than after, but we assume it is probably that as a
builtin preprocessor it does some processing on the raw book source,
and not just the JSON data.
Also a real use for Python pattern matching? I know I was surprised too.
Change-Id: Ibe8b59e7b5bd5f357a655d8b4c5f0b0f58a67d6b
This reverts commit 7095423374.
This seems to have broken running ninja on warm build directories, which
is not what we want. Reverted until we figure out something better
Change-Id: I9623ae078917e7c59a930bf8044a216501d4bb20
This puts the generated files where they are for the make system.
This is in preparation for further meson-mdbook stuff.
Change-Id: I934df6854a80af5ccf381cf1da0bda0187a8bcfc
For a long time `nix repl` has supported displaying documentation set on
builtins, however, it has long been convention to use Markdown comments
on Nix functions themselves for documentation. This exposes that
information to `nix repl` users in a nice and formatted way.
NixOS/rfcs#145 doc-comments are primarily what this feature is intended
to consume, however, support for lambda documentation in the repl is
experimental. We do our best effort to support the RFC here.
These changes are based on [the nix-doc library](https://github.com/lf-/nix-doc) and
are licensed under the terms described in the relevant source files.
Change-Id: Ic6fe947d39a22540705d890737e336c4720b0a22
setting this only on exceptions caused by actual fd access is not
sufficient to diagnose all errors (such as SerialisationError) in
some cases. this usually does not have any negative effects since
those errors will end up killing the process in another way. this
is not a reliable assumption though and we should be using proper
error handling (and closing connections more often, preferring to
close over keeping something open that might be in a weird state)
Change-Id: I1b792cd7ad8ba9ff0f6bd174945ab2575ff2208e
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
jade
Qyriad
eldritch horrors
Rebecca Turner
Lunaphied
Ilya K
Artemis Tosini
