fix(tvix/eval): thunk unary operator applications r/6214

Unary operator applications are thunked which can easily be observed by

  nix-instantiate --eval -E '[ (!true) (-1) ]'

Unfortunately, there are few simple expressions where this makes a
difference in the end result. Thus it only cropped up when using nixpkgs
for cross compilation: Here we would compile the expression

  !(stdenv.cc.isGNU or false)

to assemble python3Minimal's passthru attribute set (at least this seems
to be the most likely explanation from the backtraces I've studied).
This means that an unthunked

    <stdenv.cc.isGNU or false>
    OpForce
    OpInvert

would be performed in order to assemble this attribute set, causing
stdenv.cc to be evaluated too early, causing an infinite recursion.

Resolves b/273.

It seems that having a test suite that doesn't use --strict and relies
on thunks rendered as <CODE> would be beneficial for catching such
issues. I've not been able to find a test case with --strict that
demonstrates the problem fixed in this CL.

Change-Id: I640a5827b963f5b9d0f86fa2142e75e3a6bbee78
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8654
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>

1 files changed, 1 insertions, 1 deletions

diff --git a/tvix/eval/src/compiler/mod.rs b/tvix/eval/src/compiler/mod.rs
index c7061c77a02a..53854c75ab31 100644
--- a/tvix/eval/src/compiler/mod.rs
+++ b/tvix/eval/src/compiler/mod.rs
@@ -251,7 +251,7 @@ impl Compiler<'_> {
             ast::Expr::Path(path) => self.compile_path(slot, path),
             ast::Expr::Str(s) => self.compile_str(slot, s),
 
-            ast::Expr::UnaryOp(op) => self.compile_unary_op(slot, op),
+            ast::Expr::UnaryOp(op) => self.thunk(slot, op, move |c, s| c.compile_unary_op(s, op)),
 
             ast::Expr::BinOp(binop) => {
                 self.thunk(slot, binop, move |c, s| c.compile_binop(s, binop))