tvl-depot/tvix/eval
Vincent Ambo 025c67bf4d refactor(tvix/eval): flatten call stack of VM using generators
Warning: This is probably the biggest refactor in tvix-eval history,
so far.

This replaces all instances of trampolines and recursion during
evaluation of the VM loop with generators. A generator is an
asynchronous function that can be suspended to yield a message (in our
case, vm::generators::GeneratorRequest) and receive a
response (vm::generators::GeneratorResponsee).

The `genawaiter` crate provides an interpreter for generators that can
drive their execution and lets us move control flow between the VM and
suspended generators.

To do this, massive changes have occured basically everywhere in the
code. On a high-level:

1. The VM is now organised around a frame stack. A frame is either a
   call frame (execution of Tvix bytecode) or a generator frame (a
   running or suspended generator).

   The VM has an outer loop that pops a frame off the frame stack, and
   then enters an inner loop either driving the execution of the
   bytecode or the execution of a generator.

   Both types of frames have several branches that can result in the
   frame re-enqueuing itself, and enqueuing some other work (in the
   form of a different frame) on top of itself. The VM will eventually
   resume the frame when everything "above" it has been suspended.

   In this way, the VM's new frame stack takes over much of the work
   that was previously achieved by recursion.

2. All methods previously taking a VM have been refactored into async
   functions that instead emit/receive generator messages for
   communication with the VM.

   Notably, this includes *all* builtins.

This has had some other effects:

- Some test have been removed or commented out, either because they
  tested code that was mostly already dead (nix_eq) or because they
  now require generator scaffolding which we do not have in place for
  tests (yet).

- Because generator functions are technically async (though no async
  IO is involved), we lose the ability to use much of the Rust
  standard library e.g. in builtins. This has led to many algorithms
  being unrolled into iterative versions instead of iterator
  combinations, and things like sorting had to be implemented from scratch.

- Many call sites that previously saw a `Result<..., ErrorKind>`
  bubble up now only see the result value, as the error handling is
  encapsulated within the generator loop.

  This reduces number of places inside of builtin implementations
  where error context can be attached to calls that can fail.
  Currently what we gain in this tradeoff is significantly more
  detailed span information (which we still need to bubble up, this
  commit does not change the error display).

  We'll need to do some analysis later of how useful the errors turn
  out to be and potentially introduce some methods for attaching
  context to a generator frame again.

This change is very difficult to do in stages, as it is very much an
"all or nothing" change that affects huge parts of the codebase. I've
tried to isolate changes that can be isolated into the parent CLs of
this one, but this change is still quite difficult to wrap one's mind
and I'm available to discuss it and explain things to any reviewer.

Fixes: b/238, b/237, b/251 and potentially others.
Change-Id: I39244163ff5bbecd169fe7b274df19262b515699
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8104
Reviewed-by: raitobezarius <tvl@lahfa.xyz>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-03-13 20:30:59 +00:00
..
benches fix(tvix/eval): fix current clippy warnings 2022-12-25 18:25:06 +00:00
builtin-macros refactor(tvix/eval): flatten call stack of VM using generators 2023-03-13 20:30:59 +00:00
docs docs(tvix/eval): add proposal for VM loop restructuring 2023-02-16 22:23:51 +00:00
proptest-regressions/value refactor(tvix/eval): flatten call stack of VM using generators 2023-03-13 20:30:59 +00:00
src refactor(tvix/eval): flatten call stack of VM using generators 2023-03-13 20:30:59 +00:00
tests feat(tvix/eval): use EvalIO::import_path when coercing paths 2022-12-21 22:59:18 +00:00
.skip-subtree feat(tvix/tests): check in Nix' language test suite 2022-08-24 21:25:41 +00:00
build.rs feat(tvix/eval): implement builtins.currentSystem 2022-10-24 12:20:01 +00:00
Cargo.toml feat(tvix/eval): introduce generators module 2023-03-07 22:04:59 +00:00
default.nix refactor(tvix): build Rust projects using crate2nix 2022-12-15 17:26:45 +00:00
README.md docs(tvix): move most of //tvix/eval README up to //tvix 2023-01-21 15:08:38 +00:00

Tvix Evaluator

This project implements an interpreter for the Nix programming language. You can experiment with an online version of the evaluator: tvixbolt.

The interpreter aims to be compatible with nixpkgs, on the foundation of Nix 2.3.

Important note: The evaluator is not yet feature-complete, and while the core mechanisms (compiler, runtime, ...) have stabilised somewhat, a lot of components are still changing rapidly.

Please contact TVL with any questions you might have.

Building tvix-eval

Please check the README.md one level up for instructions on how to build this.

The evaluator itself can also be built with standard Rust tooling (i.e. cargo build).

If you would like to clone only the evaluator and build it directly with Rust tooling, you can do:

git clone https://code.tvl.fyi/depot.git:/tvix/eval.git tvix-eval

cd tvix-eval && cargo build

Nix test suite

C++ Nix implements a language test suite in the form of Nix source code files, and their expected output. The coverage of this test suite is not complete, but we intend to be compatible with it.

We have ported the test suite to Tvix, but do not run it by default as we are not yet compatible with it.

You can run the test suite by enabling the nix_tests feature in Cargo:

cargo test --features nix_tests

rnix-parser

Tvix is written in memory of jD91mZM2, the author of rnix-parser who sadly passed away.

Tvix makes heavy use of rnix-parser in its bytecode compiler. The parser is now maintained by Nix community members.