about summary refs log tree commit diff
path: root/tvix/eval/src/tests/tvix_tests
AgeCommit message (Collapse)AuthorFilesLines
2022-09-07 r/4690 test(tvix/eval): test very simple late-bound identifier accessVincent Ambo2-0/+5
This is the simplest kind of thunk that can be created (and so far the only one the compiler knows how to create), in which an identifier inside a `let` encounters a value that is bound *after* it is initialised. Change-Id: I6ea4408a3baef1e7d5137365d70804283f2dbf8e Reviewed-on: https://cl.tvl.fyi/c/depot/+/6354 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4689 feat(tvix/eval): always emit OpForce as the last instructionVincent Ambo2-0/+8
Change-Id: Id70c987f654dc5d9b47db74e395281309762b468 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6353 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4671 test(tvix/eval): add a test case for nested, deferred upvaluesVincent Ambo2-0/+7
This test case was previously broken by the bug introduced by confusing local and stack indexes. Change-Id: Ibef299dad266c6105deac1da5dde112fe9f640b1 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6341 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4669 feat(tvix/eval): emit OpFinalise when local scopes are completeVincent Ambo2-0/+5
With this change, the runtime can correctly capture deferred upvalues. Change-Id: I1e43b7b1ac2553b1812424adfc8bd08ef77bf1ea Reviewed-on: https://cl.tvl.fyi/c/depot/+/6339 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4659 fix(tvix/eval): instantiate *new* closures from blueprints each timeVincent Ambo2-0/+8
The previous closure refactoring introduced a bug in which the same closure object would get mutated constantly for each instance of a closure, which is incorrect behaviour. This commit instead introduces an explicit new Value variant for the internal "blueprint" that the compiler generates (essentially just the lambda) and uses this variant to construct the closure at runtime. If the blueprint ever leaks out to a user somehow that is a critical bug and tvix-eval will panic. As a ~treat~ test for this, the fibonacci function is being used as it is a self-recursive closure (i.e. different instantiations of the same "blueprint") getting called with different values and it's good to have it around. Change-Id: I485de675e9bb0c599ed7d5dc0f001eb34ab4c15f Reviewed-on: https://cl.tvl.fyi/c/depot/+/6323 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4658 fix(tvix/eval): correctly thread through dynamic upvaluesVincent Ambo2-0/+19
This puts together the puzzle pieces for threading dynamic upvalues (that is, upvalues resolved from the `with`-stack) all the way through. Reading the test case enclosed in this commit and walking through it is recommended to understand what problem is being tackled here. In short, because the compiler can not statically know *which* with-scope a dynamic argument is resolved from it needs to lay the groundwork for resolving from *all* possible scopes. There are multiple different approaches to doing this. The approach chosen in this commit is that if a dynamic upvalue is detected, the compiler will emit instructions to close over this dynamic value in *all* enclosing lambda contexts. It uses a new instruction for this that will leave around a sentinel value in case an identifier could not be resolved, and wire the location of this found value (or sentinel) up through the upvalues to the next level of nesting. In this tradeoff, tvix potentially closes over more upvalues than are needed (but in practice, how often do people create *really* deep `with`-stacks? and in *this* kind of code situation? maybe we should even warn for this!) but avoids keeping the entire attribute sets themselves around. Looking at the test case, each surrounding closure will close over *all* dynamic identifiers that are referenced later on visible to it, but only the last one for each identifier will actually end up being used. This also covers our bases for an additional edge-case this creates, in which an identifier potentially resolves to a dynamic upvalue *and* to a dynamic value within the function's own scope (again, would anyone really do this?) by introducing a resolution instruction for that particular case. There is likely some potential for cleaning up this code which is quite ugly in some parts, but as this implementation is now carefully calibrated to work I decided it is time to commit it and clean it up in subsequent commits. Change-Id: Ib701e3e6da39bd2c95938d1384036ff4f9fb3749 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6322 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4655 fix(tvix/eval): correctly resolve dynamic upvalues one scope upVincent Ambo4-0/+22
This does not yet correctly resolve them if they are more than one scope up, however. Change-Id: I6687073c60aee0282f2b6ffc98b34c1e96a60f20 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6319 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4653 feat(tvix/eval): implement capture of self-recursive upvaluesVincent Ambo2-0/+5
With this change, it becomes possible for functions to call themselves as they are being defined in local bindings. Change-Id: Ib46a39ba17b1452b5673d96fa729d633d237241a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6314 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4635 feat(tvix/eval): implement upvalue resolution in `with` scopesVincent Ambo2-0/+6
These need to be handled specially by the runtime if the compiler determines that a given local must be resolved via `with`. Note that this implementation has a bug: It currently allows `with` inside of nested lambdas to shadow statically known identifiers. This will be cleaned up in the next commit. Change-Id: If196b99cbd1a0f2dbb4a40a0e88cdb09a009c6b9 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6299 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4632 test(tvix/eval): add tests for very simple closuresVincent Ambo4-0/+4
Change-Id: Ib8287ade4d5df6d29e1812fb2d349cee5d92ca6a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6296 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-03 r/4610 test(tvix/eval): add a test for float representationVincent Ambo2-0/+3
Change-Id: I4893a37719b9bf08b35963d48e6851a194a08aa7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6274 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-09-03 r/4607 fix(tvix/eval): correctly escape `${` in stringsVincent Ambo1-0/+1
Without this escape, it is possible for Nix to produce escaped representations which are not literal Nix values again. This was fixed in upstream Nix in https://github.com/NixOS/nix/pull/4012 (though only for eval, not in the REPL) and the updated test is picked from upstream after that commit. Because we run the C++ Nix tests against our test suite as well, this also bumps our custom Nix 2.3 to a commit that includes the cherry-picked fix from the PR above. Change-Id: I478547ade65f655c606ec46f7143932064192283 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6271 Reviewed-by: grfn <grfn@gws.fyi> Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-02 r/4598 fix(tvix/eval): consider `let ... inherit ...` in dynamic scopesVincent Ambo2-0/+16
In conditions where no dynamic identifiers exist in a scope, inheriting is usually a no-op - *unless* the identifier is not statically known and the scope has a non-empty `with`-stack. Change-Id: Iff4138d9cd4c56e844bc574203708dacc11c3f73 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6264 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-02 r/4589 test(tvix/eval): add a simple test for builtins resolutionVincent Ambo2-0/+7
Change-Id: I91f54778b8a17f3448664c21308de656b4b04b3e Reviewed-on: https://cl.tvl.fyi/c/depot/+/6255 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-02 r/4584 feat(tvix/eval): compile function applicationsVincent Ambo2-0/+3
Change-Id: I1b9230601895a1f09ef1a8037201147020b85f36 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6250 Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-31 r/4561 feat(tvix/eval): implement scope poisoning for true/false/nullVincent Ambo4-0/+15
These tokens are optionally parsed as identifiers by Nix, which means that within any scopes that resolve them the compiler needs to track whether they have been overridden to know whether to emit the literal instructions or resolve a variable. This is implemented by a new concept of "scope poisoning", where the compiler's scope structure tracks whether or not any builtin identifiers have been overridden. Change-Id: I3ab711146e229f843f6e1f0343385382ee0aecb6 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6227 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: grfn <grfn@gws.fyi>
2022-08-31 r/4560 refactor(tvix/eval): simplify `let ... in ...` before recursionVincent Ambo2-0/+8
While full recursion through thunking is not available, there are actually incorrect behaviours introduced by declaring before binding (example in the newly introduced test). This commit simplifies the implementation to avoid this issue, and also because I intend to explore a bit more how far we can get in non left-to-right bindings *without* introducing thunks immediately. Change-Id: I21fd3007ac3946570639772d7d624d70bd209958 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6226 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: grfn <grfn@gws.fyi>
2022-08-31 r/4559 test(tvix/eval): add basic tests for with expressionsVincent Ambo4-0/+11
Change-Id: I94664090e7a2b060dfbe21c1eeb859fb31e417b0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6225 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: grfn <grfn@gws.fyi>
2022-08-31 r/4549 feat(tvix/eval): implement inherit in let expressionsVincent Ambo2-0/+9
Note that at this point recursive bindings do not yet work in either attrsets or let, so inheriting from the same scope is generally not possible yet. Change-Id: I6ca820d04b8ded5c22fb7ea18e2ec203bcaa8e9c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6215 Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-31 r/4548 feat(tvix/eval): implement `inherit` in attribute set literalsVincent Ambo4-0/+6
Straightforward implementation, evaluating the elements of an inherit and preparing the stack so that `OpAttrs` sees all relevant values when constructing the attribute set itself. The emitted instructions for inheriting a lot of values from the same attribute set are inefficient, but it's too early to say whether this actually matters. Change-Id: Icb55a20936d4ef77173f34433811c5fa5d2c9ecc Reviewed-on: https://cl.tvl.fyi/c/depot/+/6214 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-30 r/4545 feat(tvix/eval): Implement inherit from outer scope in attrsVincent Ambo2-0/+5
Change-Id: I97fa45059b7f2cbe96eb60bd1821e3e25832df66 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6212 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-30 r/4544 fix(tvix/eval): `?` operator should use OpAttrsOrNotFoundVincent Ambo2-0/+4
Using `OpAttrSelect`, the ? operator will fail when encountering a nested value that is not an attribute set. This however breaks valid code, such as: { bs = 42; } ? bs.a.b The fix is simply to use the same operator used in the `or` statement, which leaves a sentinal on the stack if a field is not found or the value is not an attribute set. Change-Id: Ib28fc8a96e6d592b4cdbc3e65ba129ad8faecd66 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6211 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-30 r/4543 fix(tvix/eval): `or` should handle non-attrset values, tooVincent Ambo2-0/+3
If a nested attrpath encounters a non-set value, the sentinel value denoting a lack of next values should be emitted. This mirrors the behaviour of Nix. Change-Id: Ia80443d5a11243cc6d98dcab1249a3f5fdf77e27 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6210 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-30 r/4542 fix(tvix/eval): allow use of ? operator on non-set typesVincent Ambo2-0/+4
Nix allows this, but always returns false. Tvix needs to do the same. Change-Id: Ic9eec90834a0d0969eea5316d5c25032d3691d94 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6209 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-30 r/4541 fix(tvix/eval): emit correct count in OpAttrPathVincent Ambo2-0/+2
Not sure how exactly this snuck in, but it caused some subtle breakages in deeply nested attribute sets. Change-Id: I8049ce912405d3750031f79cc8d86ff1c3c02c2b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6208 Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-08-29 r/4527 test(tvix/eval): add basic tests for let expressionsVincent Ambo6-0/+17
Change-Id: I788504f0c1848a1422c99006bf659738df614716 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6191 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
2022-08-26 r/4501 test(tvix/eval): add tests for the attrset `or` operatorVincent Ambo8-0/+8
Change-Id: I81f3ab94d8b987f5a4c87a27b2bcbb49cccee1ce Reviewed-on: https://cl.tvl.fyi/c/depot/+/6168 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-08-25 r/4479 feat(tvix/eval): implement list concatenationVincent Ambo2-0/+2
Change-Id: Icdf715d116371a9f139bdf95266410bf967bef25 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6144 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-08-25 r/4478 feat(tvix/eval): implement binary comparison operatorsVincent Ambo16-0/+72
This is accomplished by simply delegating to the Rust implementations of (Partial)Ord and (Partial)Eq, which are implemented for Value and underlying wrapper types to behave like they do in Nix. To ease the implementation overhead, a new comparison operator macro has been added to the VM module. Incomparable types will raise a new error variant when a comparison is attempted, containing both supplied types. This mimics the information carried in the error thrown by C++ Nix. Change-Id: Ia19634d69119d40722f3ca672387bc3a80096998 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6143 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-08-25 r/4476 feat(tvix): implement not-equals (!=) operatorVincent Ambo8-0/+8
Change-Id: Ic259d6d0cf30553e944682a0d1d2c610df7fe5c2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6141 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-08-25 r/4475 feat(tvix/eval): implement attrset update (`//`) operatorVincent Ambo8-0/+8
The underlying implementation does a few tricks based on which pair of attrset representations is encountered. Particularly the effect of short-circuiting the empty cases might be relevant in nixpkgs/NixOS, due to the use of lib.optionalAttrs. Change-Id: I22b978b1c69af12926489a71087c6a6219c012f3 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6140 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-08-25 r/4472 feat(tvix/eval): implement string concatenationVincent Ambo4-0/+4
Change-Id: If61066e59232b2bad42b5cb5f0f2d9b9c416be8b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6137 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-08-25 r/4470 test(tvix/eval): add some eval-okay-* tests for trivial typesVincent Ambo12-0/+26
Change-Id: I85ccc07e08c67abf4fcd3752c58e1702943239ac Reviewed-on: https://cl.tvl.fyi/c/depot/+/6135 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-08-24 r/4467 test(tvix/eval): add identity tests for literal evaluationVincent Ambo18-0/+36
Change-Id: Id3f37fbe341e15e9428ef1d579d61a514232c0e8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6132 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
generated by cgit-pink 1.4.1 (git 2.44.2) at 2024-12-03T16·38+0000