about summary refs log tree commit diff
path: root/tvix
AgeCommit message (Collapse)AuthorFilesLines
2022-09-07 r/4688 feat(tvix/eval): implement OpForce in VMVincent Ambo4-2/+46
This operation forces the evaluation of a thunk. There is some potential here for making an implementation that avoids some copies, but the thunk machinery is tricky to get right so the first priority is to make sure it is correct by keeping the implementation simple. Change-Id: Ib381455b02f42ded717faff63f55afed4c8fb7e3 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6352 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4682 fix(tvix/eval): allocate Thunk::upvalues with known capacityVincent Ambo1-1/+1
The capacity (i.e. number of builtins) is known from the lambda, so we can size it correctly right away. Change-Id: Iab0b5a3f47d450fa9866c091ebbbed935b934907 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6351 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4681 feat(tvix/eval): implement OpThunk for runtime thunk constructionVincent Ambo1-2/+17
Implements an operation very similar to `OpClosure` which populates a thunk's upvalues and leaves it on the stack. Change-Id: I753b4dfeeaae6919316c7028ec361aaa13d87646 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6350 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4679 refactor(tvix/eval): extract VM::populate_upvalues functionVincent Ambo1-30/+42
This function is reusable between thunks & closures. Change-Id: I44d5f9897b087a385c8e75027d2ff39c48a096f0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6349 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4678 refactor(tvix/eval): Carry lambda & upvalues directly in CallFrameVincent Ambo1-13/+25
CallFrame has to work for both thunks & closures (as a thunk is basically a "weird 0-argument closure"). We opt to store the common, relevant fields directly in the frame to avoid having to dereference through the nested structures constantly (which would be especially annoying in the case of thunks). Change-Id: I47781597b84ec5cd55502dba1713e92cf2592af3 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6348 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4677 refactor(tvix/eval): introduce UpvalueCarrier traitVincent Ambo5-18/+81
This trait abstracts over the commonalities of upvalue handling between closures and thunks. It allows the VM to simplify the code used for setting up upvalues, without duplicating between the two different types. Note that this does not yet refactor the VM code to optimally make use of this. Change-Id: If8de5181f26ae1fa00d554f1ae6ea473ee4b6070 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6347 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4676 refactor(tvix/eval): simplify thunk representationsVincent Ambo2-8/+8
For now, do not distinguish between closing and non-closing thunks, it will make the initial implementation easier. See Knuth etc. Change-Id: I0bd51e0f89f2c77e90bac63b507e5027b649e3d8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6346 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4675 feat(tvix/eval): emit thunks for recursive local scope resolutionVincent Ambo1-6/+13
When resolving a value on the same level that is known but not yet defined, emit a thunk. Consider for example: let # v--- requires a thunk a = 1 * b; b = 10; in a Change-Id: I922cb50973ebe05e335a7bc7cb851960cf34733b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6345 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4674 feat(tvix/eval): Add Compiler::thunk method for emitting thunksVincent Ambo3-1/+41
The logic in this method is *very* similar to `compile_lambda`. It is intended to be called around any expression that should be thunked (such as function applications, attribute set values, etc.). Change-Id: Idfbb2daa9f4b735095378fb9c39a2fd07c8cff91 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6344 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4673 feat(tvix/eval): introduce Value::Thunk variantVincent Ambo2-1/+61
Introduces the representation of runtime thunks, that is lazily evaluated values. Their representation is very similar to closures. Change-Id: I24d1ab7947c070ae72ca6260a7bbe6198bc8c7c5 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6343 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4672 refactor(tvix/eval): extract compiler's upvalue logic into helperVincent Ambo1-14/+20
This exact same logic is reused for thunk creation. Change-Id: I731db9cc659a1f2ca87db55d58d6ff632f417812 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6342 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/4670 fix(tvix/eval): distinguish statically between StackIdx and LocalIdxVincent Ambo2-94/+115
Previously the functions in the scope module returned usize values, which - sometimes from the same function - were either indexes into the runtime stack *or* indexes into the compiler's local stack. This is extremely confusing because it requires the caller to be aware of the difference, and it actually caused subtle bugs. To avoid this, there is now a new LocalIdx wrapper type which is used by the scope module to return indexes into the compiler's stack, as well as helpers for accounting for the differences between these indexes and the runtime indexes. Change-Id: I58f0b50ad94b28a304e3372fd9731b6590b3fdb8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6340 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4669 feat(tvix/eval): emit OpFinalise when local scopes are completeVincent Ambo3-0/+13
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/4668 feat(tvix/eval): track whether locals needs to be finalisedVincent Ambo2-0/+12
When encountering a deferred local upvalue, the compiler will now mark the corresponding local as needing a finaliser which makes it possible to emit the OpFinalise instruction for this stack slot a little bit down the line. Change-Id: I3962066f10fc6c6e1472722b8bdb415a811e0740 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6338 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4667 feat(tvix/eval): implement OpFinalise instructionVincent Ambo3-1/+28
This instruction finalises the initialisation of deferred upvalues in closures (and soon, thunks). The compiler does not yet emit this instruction, some more accounting is needed for that. Change-Id: Ic4181b26e19779e206f51e17388559400da5f93a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6337 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4666 feat(tvix/eval): set up deferred upvalues at runtimeVincent Ambo2-3/+7
This will leave a sentinel value in the upvalue slot in which the actual value is to be captured after resolution once a scope is fully set up. Change-Id: I12b37b0dc8d32603b03e675c3bd039468e70b354 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6336 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4665 feat(tvix/eval): detect deferred upvalue capturingVincent Ambo3-3/+22
Uses the threaded through slot offset to determine whether initialisation of a captured local upvalue must be defered to a later point where all values of a scope are available. This adds a new data representation to the opcode for this situation, but the equivalent runtime handling is not yet implemented. This is in part because there is more compiler machinery needed to find the resolution point. Change-Id: Ifd0c393f76abfe6e2d91483faf0f58947ab1dedc Reviewed-on: https://cl.tvl.fyi/c/depot/+/6329 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-06 r/4664 chore(tvix/eval): thread current slot index through compilerVincent Ambo1-34/+34
While compiling local bindings, we now know the stack slot of the value currently being compiled. This will let us determine whether an upvalue can be captured directly or whether it needs to wait for a synchronisation point at which the upvalue can be instantiated. This machinery lets us avoid unnecessary work at runtime when instantiating closures that actually do not need complicated recursive resolution. This change itself introduces no new functionality, but since the threading is noisy it is split out as a separate change. Change-Id: I847c677ee8f6725fda1d2efd689b6a58bdccb779 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6328 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-06 r/4663 refactor(tvix/eval): optimise initialisation of localsVincent Ambo1-23/+19
Instead of looking up the local to be initialised by its name again, we can simply track the index at which it was declared from the point where the declaration was made. This reduces some string cloning and removes unnecessary logic. It also theoretically makes the *current* index available during locals compilation, which can be used to optimise some recursion cases. Change-Id: I06f403603d4f86c3d319debfe74b5a52eec00990 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6327 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4662 refactor(tvix/eval): declare all locals before compiling themVincent Ambo1-1/+12
This actually makes things full-circle, as this tree already had this implementation once before all the other required components were in place. With this commit, the compiler can resolve recursive upvalues within the same scope (though they will not yet work at runtime). Change-Id: I6267e477d08f367257c3a6dde054b880d7b47211 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6326 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4661 refactor(tvix/eval): decouple local depth & initialisation trackingVincent Ambo2-56/+33
In order to resolve recursive references correctly, these two can not be initialised the same way as a potentially large number of (nested!) locals can be declared without initialising their depth. This would lead to issues with detecting things like shadowed variables, so making both bits explicit is preferable. Change-Id: I100cdf1724faa4a2b5a0748429841cf8ef206252 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6325 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4660 fix(tvix/eval): correct runtime error for missing dynamic upvalueVincent Ambo1-0/+6
Change-Id: I75c351619780fdc5186a54f3df9b244ada984069 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6324 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4659 fix(tvix/eval): instantiate *new* closures from blueprints each timeVincent Ambo6-17/+33
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 Ambo6-12/+112
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/4657 refactor(tvix/eval): thread dynamic upvalues through all contextsVincent Ambo2-9/+65
With this change, encountering a dynamic upvalue will thread through all contexts starting from the lowest context that has a non-empty `with`-stack. The additional upvalues are not actually used yet, so the effective behaviour remains mostly the same. This is done in preparation for an upcoming change, which will implement proper dynamic resolution for complex cases of nested dynamic upvalues. Yes, this whole upvalue + dynamic values thing is a little bit mind-bending, but we would like to not give up being able to resolve a large chunk of the scoping behaviour statically. Change-Id: Ia58cdd47d79212390a6503ef13cef46b6b3e19a2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6321 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4656 feat(tvix/eval): allow ignoring locals by prefixing with _Vincent Ambo1-1/+2
This is a common idiom in both Nix and other languages when a local is declared without actually being used. Since Tvix warns for unused locals, having this available is useful and can be included in the final error message as a suggestion if an unused variable is intentional. Change-Id: Ia85f704ba183499a3bae657c58166e2e29f9bde5 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6320 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4655 fix(tvix/eval): correctly resolve dynamic upvalues one scope upVincent Ambo5-6/+29
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/4654 fix(tvix/eval): account for stack offset when pushing a `with` scopeVincent Ambo1-1/+4
Change-Id: I4b98eaea3ed5059c29938a117a9d59499a0bb95d Reviewed-on: https://cl.tvl.fyi/c/depot/+/6318 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4653 feat(tvix/eval): implement capture of self-recursive upvaluesVincent Ambo4-7/+22
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-06 r/4652 docs(tvix/eval): start a document on known optimisation potentialVincent Ambo1-0/+57
Change-Id: I9bc41e57e1cfdf536d7b9048bac2e7aff1ee2ffa Reviewed-on: https://cl.tvl.fyi/c/depot/+/6313 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-06 r/4651 refactor(tvix/eval): encapsulate internal mutability within ClosureVincent Ambo3-25/+47
This is required to efficiently construct the upvalue array at runtime, as there are situations where during Closure construction multiple things already have a reference to the closure (e.g. a self-reference). Change-Id: I35263b845fdc695dc873de489f5168d39b370f6a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6312 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4648 docs(tvix/eval): pad pure column so it can fit "false"sterni1-107/+107
Change-Id: Iaedfc281db82de1e8eb2400db1118c8431d2579f Reviewed-on: https://cl.tvl.fyi/c/depot/+/6333 Tested-by: BuildkiteCI Autosubmit: sterni <sternenseemann@systemli.org> Reviewed-by: tazjin <tazjin@tvl.su>
2022-09-04 r/4647 docs(tvix/eval): add a list of builtins added in Nix >= 2.4sterni1-0/+11
`builtins.getFlake` doesn't interest us, of course, but some others may be worth (or easy) to implement. They are pretty low priority, though, since nixpkgs has compatiblity wrappers for the ones it uses. The new debugging-related builtins (break and traceVerbose) are interesting to note, but may not make sense to implement at all. Change-Id: Icae547aa3bd9d6ee6b87897ba8210eb9b9b044c7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6332 Tested-by: BuildkiteCI Autosubmit: sterni <sternenseemann@systemli.org> Reviewed-by: tazjin <tazjin@tvl.su>
2022-09-04 r/4646 fix(tvix/eval): don't rebuild drv upon changes in cargo target dirsterni1-1/+4
This avoids unnecessary rebuilds of //tvix/eval when working on it locally using impure cargo. Change-Id: I028033a6345a9655e2877a534448706b8f85a1a1 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6317 Tested-by: BuildkiteCI Autosubmit: sterni <sternenseemann@systemli.org> Reviewed-by: tazjin <tazjin@tvl.su>
2022-09-04 r/4643 refactor(tvix/eval): track with stack size as a simple integerVincent Ambo2-13/+24
The `With` struct no longer contained any internals after the cleanup logic for the stack had been moved into Compiler::compile_with, leaving the `Vec<With>` to essentially act as a counter for the number of things on the with stack. That's inefficient of course, so with this commit it actually becomes an integer (with an encapsulated API within scope::Scope). Change-Id: I67a00987fc8b46b30d369a96d41e83c8af5b1998 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6311 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4642 refactor(tvix/eval): move compiler's scope logic to separate moduleVincent Ambo2-172/+196
The compiler module is getting quite long and this will help keep some order. Right now the scope internals are not very well encapsulated; this paves a way to reducing the API surface of the `scope` type to the things that are actually used by the compiler instead of giving access to its internals. Change-Id: I8c16c26d263f018baa263f395c9cd80715199241 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6310 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4641 fix(tvix/eval): declare locals before marking them initialisedVincent Ambo1-1/+1
This has no effect yet, other than changing the way in which some upvalue captures break (that are already not working correctly). However, after this change the compiler correctly detects self-recursion and can start emitting the instructions to deal with this at runtime. Change-Id: Id3b0ac206c0204739597a4325bcc66f9c806c242 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6309 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4640 fix(tvix/eval): Account for uninitialised variables in with_idxVincent Ambo1-1/+11
Calculating the with_idx (i.e. the stack offset of the "phantom" variable from which a `with` dynamically reads at runtime) needs to account for unitialised variables the same way as the resolution of normal locals does. Change-Id: I9ffe404535bf1c3cb5dfe8d9e005798c857fff94 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6308 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4639 fix(tvix/eval): open/close additional scope around `with`Vincent Ambo1-0/+2
This is required to correctly clean up the `with` values. At the moment, the attrset from which identifiers are being taken is always pushed on the stack. This means that it must also be removed again, otherwise in an expression like with { a = 15; }; a The final stack is `[ { a = 15; } 15 ]` *after the last operation*, which means that the attrset is still on there as garbage. This has little practical impact right now because it is always shadowed by the fact that the actual expression value is at the right location, but becomes relevant when accounting for upvalue captures. Change-Id: I69e9745bfaa4d6bbcb60ee71f4dc3f8d8695d16a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6303 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4638 refactor(tvix/eval): extend resolve_local logic for self-recursionVincent Ambo1-22/+89
This extends the logic of `Scope::resolve_local` to detect cases where self-recursion is occuring (i.e. an identifier is being accessed in its own identifier). These cases are not yet handled specially, and the logic of when things are marked initialised (which was previously always at the same spot as their declaration) has not changed, making this commit a runtime no-op for now. Change-Id: I3179642a7c55869ad4465fdd2678b0cd51a20f15 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6302 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4637 feat(tvix/eval): detect illegally shadowed variablesVincent Ambo2-0/+34
Nix does not allow things like `let a = 1; a = 2; in a`, but doing it across depths is allowed. Change-Id: I6a259f8b01a254b433b58c736e245c9c764641b6 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6301 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4636 refactor(tvix/eval): introduce Depth enum to track variable statusVincent Ambo1-4/+26
This does not yet change anything semantically, but will be useful for resolving simple cases of self-recursion etc. Change-Id: I139ecb7e4a8a81193774392a96e73e0ea6b9f85d Reviewed-on: https://cl.tvl.fyi/c/depot/+/6300 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4635 feat(tvix/eval): implement upvalue resolution in `with` scopesVincent Ambo7-2/+47
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/4634 fix(tvix/eval): ensure OpResolveWith can be tracedVincent Ambo1-16/+16
The previous implementation of OpResolveWith manually controlled the loop iteration, which skipped over the disassembler's tracing instruction. Instead, the resolution of dynamic variables has been delegated to a new helper function. This has the additional benefit that the loop labels are no longer required, making things a bit cleaner. Change-Id: If22b74c3d49c74bf3a1ec4497cb761a9ee6cf2a4 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6298 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-04 r/4633 fix(tvix/eval): pop with stack immediately after processing bodyVincent Ambo1-13/+5
Instead of tying the popping of the with stack to scope depth, clean up the stack immediately after processing a with body. The previous behaviour was actually incorrect, as it would leave things on the with-stack longer than they were supposed to be there. This could lead to false positive resolutions in some situations involving closures. Change-Id: I7b0638557503f1f71eb602e3d5ff193cdfcb67cc Reviewed-on: https://cl.tvl.fyi/c/depot/+/6297 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/4629 feat(tvix/eval): implement runtime closure construction (OpClosure)Vincent Ambo1-1/+28
Implements the final bit of logic remaining for wiring up closures, which is the runtime construction of closure objects. When encountering an OpClosure, the VM walks through the bytecode collecting all the upvalue location operands (see commit introducing the OpCode::Data* variants for details) and stores the runtime values in the new closures upvalue vector. After that, the handling of the closure itself becomes functionally identical to that of lambdas. With this initial implementation of closures there are several large optimisation potentials available, the two most notable ones are: - Distinguish the runtime representation of lambdas and closures explicitly. - Detect and handle multiple-arity functions directly in the compiler. However, for both of these we should wait until we have appropriate benchmarking infrastructure in place. This is because our test implementations have shown that the complexity of either of these changes is quite significant, and we do not yet know if they really pay off. Change-Id: I077e977810fd5cb2b1ecd7f1a119e728025dd786 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6295 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
2022-09-03 r/4628 feat(tvix/eval): implement OpGetUpvalue in the VMVincent Ambo1-4/+6
This resolves an upvalue at runtime by pushing it on the stack from the closure's upvalue vector. Change-Id: Ic3e7a7ecd9f7032f679114a1995e5bbf83062fcf Reviewed-on: https://cl.tvl.fyi/c/depot/+/6294 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
2022-09-03 r/4627 refactor(tvix/eval): store Closure inside of the VM's call framesVincent Ambo1-6/+6
In preparation for implementing calling of closures, store a closure directly in the VMs call frame. Change-Id: Iad24cd8c49fee4ebd4d0c84ffaa4c2505ee3dfd6 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6293 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
generated by cgit-pink 1.4.1 (git 2.44.2) at 2024-11-15T11·07+0000