diff options
author | sterni <sternenseemann@systemli.org> | 2023-05-27T11·45+0200 |
---|---|---|
committer | clbot <clbot@tvl.fyi> | 2023-05-29T12·44+0000 |
commit | 385c7978841af20da9bd47a829dd1f2d3f6cdd2e (patch) | |
tree | f7f5ab54ef68d941d41d32ee2133f6b9c8325a30 /src/libstore | |
parent | 93fa47f2ae868e9476f1dd33572022ef0bed4dbf (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')
0 files changed, 0 insertions, 0 deletions