This removes static initializers for `nix` subcommands. cl/1905 made
the same change but for legacy commands.
See: #359
Change-Id: I23c99755719cef8e73fc720b685d4d1cf9b4ef15
This should be submitted as part of a stack, doesn't make too much sense
on its own, but it's mechanical and it builds it's easy to split it out
of the diff.
Change-Id: I453061482476c72a5fc6fb2662b000d79b87fc1b
ifd requires building which uses async code today, fetching requires
network io which really should use async code but does not yet. eval
itself cannot be made async for performance reasons. offloading work
to other threads is possible but questionable as currently there are
no uses in which evaluation must take place from within asynchronous
operations, which are currently confined entirely to store behavior.
Change-Id: I1e3c86fca19b042d79332e9a5ef9546f90a6448b
this finally gives us a witness type we can use to prove that a certain
call graph subtree can't be used in kj promises using only a single new
assumption: if EvalState& is never held as a reference member of a type
and instead only ever passes as an argument or held on the stack we can
be certain that anything that has access to en EvalState ref must never
be run inside a promise and, crucially, that anything that doesn't have
access to an EvalState& *can* be run inside a promise without problems.
Change-Id: I6c15ada479175ad7e6cd3e4a729a5586b3ba30d6
for the same reason the eval caches should not keep them as references,
only worse: installables cannot fully lose their reference member since
some types of installable (flakes -sigh-) need access to caches held by
their member reference. passing that around as well at all times is not
feasible; passing in EvalState& all the time is quite bad enough as is.
Change-Id: I05d438623b5ef10fc22e7e256b89447e61a0657d
this is necessary to share a debug state between multiple eval states.
while doings so makes little sense at present it will be necessary for
async io support since eval states must be async io roots, which means
we must create them as needed from a shared evaluation context object.
Change-Id: Id9d4b37aae40706f65c741e3b961855582e035ab
if we define a TraceableAllocator at all times and use that in places
that want maybe-traceable allocation we can simplify things a lot. we
also unconditionally allocate cache root pointers for Value and Env-1
caches, even though we don't need them without gc (they're so cheap).
defaulting to `std::allocator` without gc recovers previous behavior.
Change-Id: I236da8c3b0669b40cdfe355ec3ec4e764d096074
eval caches are not used by actual eval at all, only by the flake-shaped
wrappers around evaluation. moving caches into a subclass both clarifies
that eval caches and eval states are coupled and separates concerns that
should not have been intermixed as they were here. in the future we will
want to split up and decouple things even further. that'll have to wait.
Change-Id: I7b69510c0f8b212f05fae62e7b992d9475b4841f
just to keep debug-related state closer together. eventually this will
also allow us to not allocate debugger state altogether unless needed.
Change-Id: Id83fea75d96d0ecbe21683cb1b57dd5b11b13535
there are no uses of plain MultiCommand as a base class *except* in
NixArgs, which is the only one that does not implement run(). there
is not much of a reason not to implement a run member there though,
so let's just do that and get rid of this weird intermediate class.
Change-Id: Ie84e3acd071b43bc186a2bac87646cbfb3aff845
clangd broke because it can't look through symlinks. compile_commands
manipulation does not fix it, clangd configuration does not fix it, a
vfs overlay does not fix it, and while a combination of those can fix
it with a bind mount in place that's just too cursed to even consider
clangd bug: https://github.com/llvm/llvm-project/issues/116877
Change-Id: I8e3e8489548eb3a7aa65ac9d12a5ec8abf814aec
Rebecca Turner