depot - monorepo for the virus lounge

Age	Commit message (Collapse)	Author	Files	Lines
2022-09-06	r/4665 feat(tvix/eval): detect deferred upvalue capturing	Vincent Ambo	3	-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 compiler	Vincent Ambo	1	-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 locals	Vincent Ambo	1	-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 them	Vincent Ambo	1	-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 tracking	Vincent Ambo	2	-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 upvalue	Vincent Ambo	1	-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 time	Vincent Ambo	6	-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 upvalues	Vincent Ambo	6	-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 contexts	Vincent Ambo	2	-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