about summary refs log tree commit diff
path: root/tvix/eval/src/compiler
AgeCommit message (Collapse)AuthorFilesLines
2022-09-07 r/4727 feat(tvix/eval): track source spans for identifier accessVincent Ambo1-10/+8
Change-Id: I8e6ec0a84430d6e417fc7fd3e722a588913e4d18 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6394 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-07 r/4726 feat(tvix/eval): track source spans for `let` bindingsVincent Ambo1-2/+2
Change-Id: I9457917277a7fdd8bdbe227a567b28969312d06e Reviewed-on: https://cl.tvl.fyi/c/depot/+/6393 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-07 r/4725 feat(tvix/eval): track source spans for `if` expressionsVincent Ambo1-4/+7
These are again a bit tricky in terms of emitted errors. The main error is that the condition is not a boolean, which means that the jump inspecting the condition must derive from the condition itself to return an error at the correct position. For other parts of the expression, it is simply the node itself. Change-Id: I72411630e5d57dfc199f4c3c48afe443fe966322 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6392 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4724 feat(tvix/eval): track source spans for `assert`Vincent Ambo1-1/+1
Change-Id: I5415f63ddde388847a261da4ce9a8d8235657535 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6391 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4723 feat(tvix/eval): track source spans for `or` operatorVincent Ambo1-7/+4
This one is tricky, specifically the span used for the final jump. I decided that it makes sense to use the attrpath node, as the final jump is the one that jumps *over* the default value, so the effect of this is more closely related to the selector than the default. It might be more correct to pass through the `or` token itself and point to this for the jumps, but it depends a bit on what shape of errors we could end up producing from this. Change-Id: I29fbc97ba6b9e14e1a0e5f3a7759ddc299dd9c0c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6390 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4722 feat(tvix/eval): track source spans for attribute selectsVincent Ambo1-1/+1
Change-Id: Ifa8b0e7905f9d2746f83d6503ef0e8d42ce20f9c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6389 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4721 feat(tvix/eval): track source spans for attrsetsVincent Ambo1-3/+6
Change-Id: I0fcb07146b5a38c67bc46ed3f67533b056858390 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6388 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4720 feat(tvix/eval): track source spans for listsVincent Ambo1-1/+1
Change-Id: Icfd057ee29180cac17264bb3299c67eae0051aee Reviewed-on: https://cl.tvl.fyi/c/depot/+/6387 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4719 feat(tvix/eval): track source spans for literal identifiersVincent Ambo1-1/+4
Change-Id: I7ca08c6c0124f653e55fcc86413a847f0a4c50c5 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6386 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4718 feat(tvix/eval): track source spans for `?` operatorVincent Ambo1-2/+2
Change-Id: Idb842fb20fab14150455a81ea6c947e75b314d8a Reviewed-on: https://cl.tvl.fyi/c/depot/+/6385 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4717 feat(tvix/eval): track source spans for binary operatorsVincent Ambo1-23/+23
Change-Id: I43e433ff3094232b244d38335d31e56a79ca70c1 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6384 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4716 feat(tvix/eval): track source spans for unary operatorsVincent Ambo1-1/+1
Change-Id: I79034a4aa04aea66ec598e33e6eab35e1e19c0d0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6383 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4715 feat(tvix/eval): track source spans for stringsVincent Ambo1-2/+2
Change-Id: I29e6c7f9e25d1b2e6bafa602c463eb9ccee2131b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6382 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4714 feat(tvix/eval): track source spans for pathsVincent Ambo1-1/+1
Change-Id: I42fbd0bb6c2a8feb520e262a25f59ff27dcd035c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6381 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4713 feat(tvix/eval): track source spans for literalsVincent Ambo1-3/+3
Change-Id: Icfe77f85c4f65b6bf28b8752c2795419e8e396ce Reviewed-on: https://cl.tvl.fyi/c/depot/+/6380 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4712 feat(tvix/eval): add methods for emitting code with tracked spansVincent Ambo1-79/+103
These are not actually used yet; this is in preparation for a multi-commit chain for emitting all the right spans in the right locations. Change-Id: Ie99d6add2696c1cc0acb9ab928917a10237159de Reviewed-on: https://cl.tvl.fyi/c/depot/+/6379 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4711 chore(tvix/eval): thread a codemap::File reference to the compilerVincent Ambo1-4/+11
This instantiates a codemap outside of the compiler and passes a reference to the file currently under compilation to it. Note that the "file" might just be a REPL line. Change-Id: I131ae1ddb6d718e1374750da9ba0b99608c6058d Reviewed-on: https://cl.tvl.fyi/c/depot/+/6378 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4710 refactor(tvix/eval): add and use Compiler::push_op methodVincent Ambo1-60/+65
This is currently just a wrapper around Chunk::push_op, but will gain the span resolution logic in a moment. Change-Id: I862bf9ecff0932f8da6708401ea044b9442c5d5b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6377 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4706 fix(tvix/eval): address current clippy lintsVincent Ambo1-2/+2
Note that I've allowed `needless_lifetimes` for the attribute set iterator, as I find the type easier to understand with these annotations present. Change-Id: I33abb17837ee4813076cdb9a87f54bac4a37044e Reviewed-on: https://cl.tvl.fyi/c/depot/+/6373 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-07 r/4699 feat(tvix/eval): construct attribute sets lazilyVincent Ambo1-2/+10
This thunks the construction of attribute sets. Because Tvix does not currently have a "strict output" mode, a test had to be disabled that now displays a thunk representation. The test will be re-enabled once that is available. Change-Id: I360332be64cd5c154f9caea21828f6f1b37a265c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6363 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4696 fix(tvix/eval): correctly resolve identifiers in inheritVincent Ambo1-21/+4
This should not have grown a second implementation of the identifier resolution logic, but it somehow did. This implementation ended up being incorrect because it did not account for upvalues inside of thunks. Change-Id: Ieb1364d8fe43c96aaf4b125fd4b8a522aedff167 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6360 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4695 chore(tvix/eval): implement Debug for compiler::scope::ScopeVincent Ambo1-1/+2
Change-Id: I112b0119bd0511f26bb72f7e73d867d1b7144a36 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6359 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4694 feat(tvix/eval): insert strictness points for attribute set keysVincent Ambo1-2/+10
All attribute set *key* related operations strictly evaluate all key fragments, including during construction of an attribute set. Change-Id: I3519e5e9b0886c2cdc8615ea7dcb5f7be0c59b3f Reviewed-on: https://cl.tvl.fyi/c/depot/+/6358 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4693 feat(tvix/eval): insert strictness points for unary/binary operatorsVincent Ambo1-1/+17
The arguments of all unary/binary operators that are built in to Nix are forced when encountered. This emits the necessary OpForce operations. Change-Id: I691fcdbebfe7586cfe217c68d44b10b1192f82d1 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6357 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4692 chore(tvix/eval): thread `slot` value through all compiler methodsVincent Ambo1-54/+58
With this change any compilation of an expression is aware of its own stack slot if it is leaving identifiers on the stack. Change-Id: I0c9f148ae06b078a46b25180c4961686d5f2e166 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6356 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4691 chore(tvix/eval): thread `slot` value through Compiler:compile_attrVincent Ambo1-17/+23
This threads the current local slot through the `compile_attr` function and all of its callers. At the moment this does not improve any user-facing behaviour, just internally changes the way in which some correct expressions would fail to run. Eventually this slot will need to reach everywhere ... Change-Id: Iba73123dd1ced421093d8fc18ebeeffc16efacf8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6355 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-07 r/4689 feat(tvix/eval): always emit OpForce as the last instructionVincent Ambo1-0/+6
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/4676 refactor(tvix/eval): simplify thunk representationsVincent Ambo1-1/+1
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 Ambo1-1/+36
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/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/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 Ambo1-0/+8
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/4665 feat(tvix/eval): detect deferred upvalue capturingVincent Ambo1-3/+16
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/4659 fix(tvix/eval): instantiate *new* closures from blueprints each timeVincent Ambo1-3/+4
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 Ambo1-4/+20
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 Ambo1-6/+7
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 Ambo1-4/+8
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/4651 refactor(tvix/eval): encapsulate internal mutability within ClosureVincent Ambo1-2/+1
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/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>
generated by cgit-pink 1.4.1 (git 2.44.2) at 2024-11-15T07·46+0000