about summary refs log tree commit diff
path: root/src/libstore/nar-info.cc
diff options
context:
space:
mode:
authorsterni <sternenseemann@systemli.org>2023-05-27T11·45+0200
committerclbot <clbot@tvl.fyi>2023-05-29T12·44+0000
commit385c7978841af20da9bd47a829dd1f2d3f6cdd2e (patch)
treef7f5ab54ef68d941d41d32ee2133f6b9c8325a30 /src/libstore/nar-info.cc
parent93fa47f2ae868e9476f1dd33572022ef0bed4dbf (diff)
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>
Diffstat (limited to 'src/libstore/nar-info.cc')
0 files changed, 0 insertions, 0 deletions