3b33c19a9c
mapAttrs, map and genList call Nix functions provided by the caller and
store the result of applying them in a Nix data structure that does not
force all of its contents when forced itself. This means that when such
a builtin application is forced, the Nix function calls performed by the
builtin should not be forced: They may be forced later, but it is also
possible that they will never be forced, e.g. in
builtins.length (builtins.map (builtins.add 2) [ 1 2 3 ])
it is not necessary to compute a single application of builtins.add.
Since request_call_with immediately performs the function call
requested, Tvix would compute function applications unnecessarily before
this change. Because this was not followed by a request_force, the
impact of this was relatively low in Nix code (most functions return a
new thunk after being applied), but it was enough to cause a lot of
bogus builtins.trace applications when evaluating anything from
`lib.modules`. The newly added test includes many cases where Tvix
previously incorrectly applied a builtin, breaking a working expression.
To fix this we add a new helper to construct a Thunk performing a
function application at runtime from a function and argument given as
`Value`s. This mimics the compiler's compile_apply(), but does itself
not require a compiler, since the necessary Lambda can be constructed
independently.
I also looked into other builtins that call a Nix function to verify
that they don't exhibit such a problem:
- Many builtins immediately use the resulting value in a way that makes
it necessary to compute all the function calls they do as soon as
the outer builtin application is forced:
* all
* any
* filter
* groupBy
* partition
- concatMap needs to (shallowly) force the returned list for
concatenation.
- foldl' is strict in the application of `op` (I added a comment that
makes this explicit).
- genericClosure needs to (shallowly) force the resulting list and some
keys of the attribute sets inside.
Resolves b/272.
Change-Id: I1fa53f744bcffc035da84c1f97ed25d146830446
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8651
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
|
||
|---|---|---|
| .. | ||
| benches | ||
| builtin-macros | ||
| docs | ||
| proptest-regressions/value | ||
| src | ||
| tests | ||
| .skip-subtree | ||
| build.rs | ||
| Cargo.toml | ||
| default.nix | ||
| README.md | ||
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.