about summary refs log tree commit diff
path: root/tvix/eval/src/compiler/attrs.rs
AgeCommit message (Collapse)AuthorFilesLines
2022-09-16 r/4876 feat(tvix/eval): implement recursive attribute setsVincent Ambo1-12/+10
Yep. This is kind of ugly right now. The idea is that the recursive_scope compilation function is used for recursive sets as well by emitting the keys. The rest of the logic is pretty much identical. There is quite a lot of code here that can be cleaned up (duplication between attrs and let, duplication inside of the recursive scope compilation function etc.), but I'd like to get it working first and then make it nice. Note that nested keys are *not* supported yet. Change-Id: I45c7cdd5f0e1d35fd94797093904740af3a97134 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6610 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-16 r/4873 refactor(tvix/eval): move compile_inherit_attrs to compiler::attrsVincent Ambo1-0/+62
Plain move, no other changes. Change-Id: Ic4f89709f5c2cbc03182a848af080c820e39a0fd Reviewed-on: https://cl.tvl.fyi/c/depot/+/6607 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-16 r/4872 refactor(tvix/eval): explicitly construct attrs in phasesVincent Ambo1-32/+100
This makes the phases of attribute set construction that Nix has very explicit (inherits, static keys, dynamic keys). This change focuses on the split between dynamic/static keys by collecting all dynamic ones while compiling the static ones, and then phasing them in afterwards. It's possible we also need to do some additional splitting inside of the inherits. Change-Id: Icae782e2a5c106e3ce0831dda47ed81c923c0a42 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6530 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-13 r/4849 fix(tvix/eval): force left argument of `?` before checking for attrssterni1-0/+2
OpAttrsIsSet and OpAttrsTrySelect will fail silently if the attribute set value on the stack is actually a thunk, so we need to make sure to force at every step of the way. Emitting the force instructions in the compiler because it is easier to add, but maybe the VM should do this when handling the relevant opcodes? Comments welcome. Change-Id: I65c5ef348d59b2d07c9bb06abb24f9f3e6a0fdb2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6540 Reviewed-by: grfn <grfn@gws.fyi> Autosubmit: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su>
2022-09-13 r/4844 fix(tvix/eval): use fragment span for OpAttrsSelectVincent Ambo1-2/+2
Pointed out by sterni in cl/6389 Change-Id: I648056a760266a8cfd7adcdc478c7ff2132991f7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6568 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-13 r/4840 refactor(tvix/eval): encapsulate scope_depth in compiler::scopeVincent Ambo1-2/+2
This field no longer needs to be directly accessible by the compiler. Addresses a sterni lint from cl/6466 Change-Id: I5e6791943d7f0ab3d9b7a30bb1654c4a6a435b1f Reviewed-on: https://cl.tvl.fyi/c/depot/+/6564 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI
2022-09-13 r/4830 feat(tvix/eval): implement initial fancy display for warningsVincent Ambo1-1/+1
This implements an initial fancy display for warnings emitted by the tvix compiler, using the codemap_diagnostic crate. Each warning variant has an associated message, and optionally an associated annotation for the span displayed to the user. In theory we could get a lot more fancy with the display for specific variants if needed (e.g. re-parse the AST and actually add multiple semantic spans based on context), but this is already a good start. Example: tvix-repl> let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} warning[W004]: declared variable 'toString' shadows a built-in global! --> [tvix-repl]:1:5 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^^^^^^^ variable declared here warning[W001]: URL literal syntax is deprecated, use a quoted string instead --> [tvix-repl]:1:16 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^^^^^^^^^^^^^^ warning[W002]: inherited variable already exists with the same value --> [tvix-repl]:1:40 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^^^^^^^^^^^^^^^^ warning[W999]: feature not yet implemented in tvix: recursive attribute sets --> [tvix-repl]:1:70 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^^^^^ warning[W999]: feature not yet implemented in tvix: closed formals --> [tvix-repl]:1:62 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^ warning[W003]: variable 'toString' is declared, but never used: --> [tvix-repl]:1:5 | 1 | let toString = https://tvl.fyi; in let inherit toString; in ({}: 42) rec {} | ^^^^^^^^ variable declared here => 42 :: int These are coloured when output to a terminal. Change-Id: If315648a07e333895db4ae1d0915ee2013806585 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6532 Autosubmit: tazjin <tazjin@tvl.su> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI
2022-09-11 r/4823 refactor(tvix/eval): remove `todo!()` calls in compilerVincent Ambo1-1/+5
It is impossible for tvixbolt to recover from panics, so the user experience of typing an expression using an unsupported feature was that it would get sad and stop responding to input. Instead, raise a normal value-level error of a new variant and continue where possible. Change-Id: Ibe016c92cacb87b85095c0f83758eddc6468053e Reviewed-on: https://cl.tvl.fyi/c/depot/+/6528 Autosubmit: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-11 r/4814 fix(tvix/eval): pass correct slot when compiling attr valuesVincent Ambo1-1/+1
Change-Id: I90722d59dea4c7694eb5a7cf505db31196ba6c6c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6501 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2022-09-11 r/4810 refactor(tvix/eval): move attrset-related code to compiler::attrsVincent Ambo1-0/+208
There's about to be a lot more code for attrsets (hopefully temporarily as part of an expand&contract cycle), while nested attribute logic is being refactored in preparation for recursive attribute sets. This does not change any functionality. Change-Id: I667565cd810ca7d9046120d1721c2ceb9095550b Reviewed-on: https://cl.tvl.fyi/c/depot/+/6497 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>