tvl-depot/tvix/eval
Vincent Ambo 3419f63575 fix(tvix/eval): ensure all evaluated thunks are correctly memoized
This fixes a very complicated bug (b/246). Evaluation
progresses *much* further after this, leading to several less
complicated bugs likely being uncovered by this

What was the problem?
=====================

Previously, when evaluating a thunk, we had a code path that looked
like this:

    match *thunk {
        ThunkRepr::Evaluated(Value::Thunk(ref inner_thunk)) => {
            let inner_repr = inner_thunk.0.borrow().clone();
            drop(thunk);
            self.0.replace(inner_repr);
        }
        /* ... */
    }

This code path created a copy of the inner `ThunkRepr` of a nested
thunk, and moved that copy into the `ThunkRepr` of the parent.

The effect of this was that the original `ThunkRepr` (unforced!) lived
on in the original thunk, without the memoization of the subsequent
forcing applying to it.

This had the result that Tvix would repeatedly evaluate these thunks
without ever memoizing them, if they occured repeatedly as shared
inner thunks. Most notably, this would *always* occur when
builtins.import was used.

What's the solution?
====================

I have completely rewritten `Thunk::force_trampoline_self` to make all
flows that can occur in it explicit. I have also removed the outer
loop inside of that function, and resorted to more use of trampolining
instead.

The function is now well-commented and it should be possible to read
it from top-to-bottom and get a general sense of what is going on,
though the trampolining itself (which is implemented in the VM) needs
to be at least partially understood for this.

What's the new problem(s)?
==========================

One new (known) problem is that we have to construct `Error` instances
in all error types here, but we do not have spans available in some
thunk-related situations. Due to b/238 we cannot ask the VM for an
arbitrary span from the callsite leading to the force. This means that
there are now code paths where, under certain conditions, causing an
evaluation error during thunk forcing will panic.

To fix this we will need to investigate and fix b/238, and/or add a
span tracking mechanism to thunks themselves.

What other impacts does this have?
==================================

With this commit, eval of nixpkgs mostly succeeds (things like stdenv
evaluate to the same hashes for us and C++ Nix, meaning we now
construct identical derivations without eval breaking).

Due to this we progress much further into nixpkgs, which lets us
uncover more additional bugs. For example, after this commit we can
quickly see that cl/7949 introduces some kind of behavioural issue and
should not be merged as-is (this was not apparent before).

Additionally, tvix-eval is now seemingly very fast. When doing
performance analysis of a nixpkgs eval, we now mostly see the code
path for shelling out to C++ Nix to add things to the store in there.
We still need those code paths, so we can not (yet) do a performance
analysis beyond that.

Change-Id: I738525bad8bc5ede5d8c737f023b14b8f4160612
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8012
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
2023-02-03 10:47:18 +00:00
..
benches fix(tvix/eval): fix current clippy warnings 2022-12-25 18:25:06 +00:00
builtin-macros feat(tvix/eval): let builtin macro capture external state 2023-01-20 15:39:51 +00:00
docs docs(tvix/eval): builtins.add is not equivalent to + 2023-01-25 14:30:50 +00:00
proptest-regressions/value test(tvix/eval): Add tests for the Eq laws of Value 2022-09-18 17:57:09 +00:00
src fix(tvix/eval): ensure all evaluated thunks are correctly memoized 2023-02-03 10:47:18 +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): implement builtins.fromTOML 2023-01-25 07:49:44 +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.