depot/tvix/eval/src/eval.rs, branch refs/r/6808 monorepo for the virus lounge http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F6808 2022-12-21T13:09:29+00:00 refactor(tvix): split binary (REPL etc.) out from evaluator library 2022-12-21T13:09:29+00:00 Vincent Ambo mail@tazj.in 2022-12-08T21:19:22+00:00 urn:sha1:d9e2bec953880ecb5953b61b36a5beaec0565e22 The tvix-eval project is independent from any *uses* of the evaluator, such as the tvix-repl. This functionality has been split out into a separate "tvix-cli" crate. Note that this doesn't have to mean that this CLI crate is the "final" CLI crate for tvix, the point of this is not "getting the CLI structure right" but rather "getting the evaluator structure right". This reshuffling is part of restructuring the way that functionality like store communication is injected into language evaluation. Note that at this commit the new CLI crate is not at feature-parity. Change-Id: Id0af03dc8e07ef09a9f882a89612ad555eca8f93 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7541 Autosubmit: tazjin <tazjin@tvl.su> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI feat(tvix/eval): add --raw flag to eval, like cppnix 2022-11-26T21:20:02+00:00 Adam Joseph adam@westernsemico.com 2022-11-25T22:47:39+00:00 urn:sha1:b5a1b965a6892d35b06ab315a531c718e02cd267 Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: If07250a45fdf65a3f22ed8c37d7f37b45edccde9 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7416 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> feat(tvix/eval): builtins.import without RefCell 2022-10-27T21:36:01+00:00 Adam Joseph adam@westernsemico.com 2022-10-26T12:16:04+00:00 urn:sha1:8616f13a71e3fc186e01bdb4ada60503f233be99 CL/6867 added support for builtins.import, which required a cyclic reference import->globals->builtins->import. This was implemented using a RefCell, which makes it possible to mutate the builtins during evaluation. The commit message for CL/6867 expressed a desire to eliminate this possibility: This opens up a potentially dangerous footgun in which we could mutate the builtins at runtime leading to different compiler invocations seeing different builtins, so it'd be nice to have some kind of "finalised" status for them or some such, but I'm not sure how to represent that atm. This CL replaces the RefCell with Rc::new_cyclic(), making the globals/builtins immutable once again. At VM runtime (once opcodes start executing) everything is the same as before this CL, except that the Rc<RefCell<>> introduced by CL/6867 is turned into an rc::Weak<>. The function passed to Rc::new_cyclic works very similarly to overlays in nixpkgs: a function takes its own result as an argument. However instead of laziness "breaking the cycle", Rust's Rc::new_cyclic() instead uses an rc::Weak. This is done to prevent memory leaks rather than divergence. This CL also resolves the following TODO from CL/6867: // TODO: encapsulate this import weirdness in builtins The main disadvantage of this CL is the fact that the VM now must ensure that it holds a strong reference to the globals while a program is executing; failure to do so will cause a panic when the weak reference in the builtins is upgrade()d. In theory it should be possible to create strong reference cycles the same way Rc::new_cyclic() creates weak cycles, but these cycles would cause a permanent memory leak -- without either an rc::Weak or RefCell there is no way to break the cycle. At some point we will have to implement some form of cycle collection; whatever library we choose for that purpose is likely to provide an "immutable strong reference cycle" primitive similar to Rc::new_cyclic(), and we should be able to simply drop it in. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: I34bb5821628eb97e426bdb880b02e2097402adb7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7097 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> feat(tvix/eval): add an AST pretty-printing module 2022-10-16T12:26:56+00:00 Vincent Ambo mail@tazj.in 2022-10-13T12:23:45+00:00 urn:sha1:0abc66ad91b8bcc25aeb7f3d086fcc52529ec8e8 This implements serde::Serialize for the rnix AST through a wrapper type, and exposes a function for serialising the AST into a (pretty-printed JSON) string representation. This can be used to debug issues with the AST, and to display an AST reprsentation in tools like tvixbolt. Serialize is implemented manually because we don't own any of the structs and the way to traverse them is not easily derived automatically, and this is quite verbose. We might be able to condense it a little bit, but at the same time it's also fairly straightforward. Change-Id: I922df43cfc25636f3c8baee7944c75ade516055c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6943 Autosubmit: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI Reviewed-by: Adam Joseph <adam@westernsemico.com> Reviewed-by: tazjin <tazjin@tvl.su> feat(tvix/eval): allow to disable warnings 2022-10-13T02:49:59+00:00 Adam Joseph adam@westernsemico.com 2022-10-12T06:18:25+00:00 urn:sha1:e83609a06195642f472b112ffa95f001fde8ef60 The nix_tests test suite produces lots of warnings. We can't fix these, since they are kept in sync with upstream, so there's little point in cluttering up the console with them every time the tests are run. Let's add a clap flag "warnings" and TVIX_WARNINGS environment variable. The default is "true". The test runner overrides this default and mutes the warnings. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: I4b065f96fe15838afcca6970491a54e248ae4df7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6985 Reviewed-by: tazjin <tazjin@tvl.su> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI refactor(tvix/eval) s/NixPath/NixSearchPath/ 2022-10-12T08:09:49+00:00 Adam Joseph adam@westernsemico.com 2022-10-10T18:43:51+00:00 urn:sha1:32ac7d6c6d06b5191fcc828b762b247b0e27dfda Since NixString is the Rust type for nix strings, people might mistake NixPath for the Rust type of nix paths, which it is not. Let's call it NixSearchPath instead. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: Ib2ea155c4b27cb90d6180a04ea7b951d86607373 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6927 Reviewed-by: kanepyork <rikingcoding@gmail.com> Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> feat(tvix/eval): Initial resolution of `<...>` paths 2022-10-10T20:23:41+00:00 Griffin Smith root@gws.fyi 2022-10-10T03:46:51+00:00 urn:sha1:273ba73754e9b10f768830d5a6835bf3d14e0d8a This commit implements (lazy) resolution of `<...>` paths via either the NIX_PATH environment variable, or the -I command-line flag - both handled via EvalOptions. As a result, EvalOptions can no longer derive Copy, meaning we have to clone it at each line of the repl - this is probably not a huge deal as repl performance is not exactly an inner loop and we're not cloning very much. Internally, this works by creating a thunk which pushes a constant containing the string inside the brackets to the stack, then a new opcode to resolve that path via the `NixPath`. To get that opcode to work, we now have to pass in the NixPath when constructing the VM. This (intentionally) leaves out proper implementation of path resolution via `findFile` (cppnix just calls whatever identifier called findFile is in scope!!!) as that's widely considered a bit of a misfeature, but if we do decide to implement that down the road it likely wouldn't be more than a few extra ops within the thunk introduced here. Change-Id: Ibc979b7e425b65cbe88599940520239a4a10cee2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6918 Autosubmit: grfn <grfn@gws.fyi> Reviewed-by: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI feat(tvix/eval): fancy-format parse errors returned by rnix 2022-10-08T17:27:57+00:00 Vincent Ambo mail@tazj.in 2022-10-06T14:22:17+00:00 urn:sha1:1e2d323a7c5b554f69902987b57c9d47d57e7eea This change is quite verbose, so a little bit of explaining: 1. To correctly format parse errors, errors must be able to return more than one annotated span (the parser returns a list of errors for each span). To accomplish this, the structure of how the `Diagnostic` struct which formats an error is constructed has changed to delegate the creation of the `SpanLabel` vector to the kind of error. 2. The rnix structures don't have human-readable output formats by default, so some verbose methods for formatting them in human-readable ways have been added in the errors module. We might want to move these out into a submodule. 3. In many cases, the errors returned by rnix are a bit strange - so while we format them with all information that is easily available they may look weird or not necessarily help users. Consider this CL only a first step in the right direction. Change-Id: Ie7dd74751af9e7ecb35d751f8b087aae5ae6e2e8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6871 Reviewed-by: sterni <sternenseemann@systemli.org> Autosubmit: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI feat(tvix/eval): add method for emitting runtime warnings 2022-10-07T14:24:36+00:00 Vincent Ambo mail@tazj.in 2022-10-05T14:01:07+00:00 urn:sha1:07e03498f26afbf647102d656c90d447f8586820 This lets the VM emit warnings when it encounters situations that should only be warned about at runtime. For starters, this is used to pass through compilation warnings that come up when `import` is used. Change-Id: I0c4bc8c534d699999887c430d93629fadfa662c4 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6868 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI feat(tvix/eval): insert `import` into the builtins itself 2022-10-07T14:24:36+00:00 Vincent Ambo mail@tazj.in 2022-10-04T20:58:21+00:00 urn:sha1:4b9178fa2ae4cab718225f6136791df1d11814ee Adding `import` to builtins causes causes a bootstrap cycle because the `import` builtin needs to be initialised with the set of globals before being inserted into the globals, which also must contain itself. To break out of the cycle this hack wraps the builtins passed to the compiler in an `Rc` (probably sensible anyways, as they will end up getting cloned a bunch), containing a RefCell which gives us mutable access to the builtins. This opens up a potentially dangerous footgun in which we could mutate the builtins at runtime leading to different compiler invocations seeing different builtins, so it'd be nice to have some kind of "finalised" status for them or some such, but I'm not sure how to represent that atm. Change-Id: I25f8d4d2a7e8472d401c8ba2f4bbf9d86ab2abcb Reviewed-on: https://cl.tvl.fyi/c/depot/+/6867 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<feed xmlns="http://www.w3.org/2005/Atom">
<title>depot/tvix/eval/src/eval.rs, branch refs/r/6808</title>
<subtitle>monorepo for the virus lounge</subtitle>
<id>http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F6808</id>
<link rel="self" href="http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F6808"/>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/"/>
<updated>2022-12-21T13:09:29+00:00</updated>
<entry>
<title>refactor(tvix): split binary (REPL etc.) out from evaluator library</title>
<updated>2022-12-21T13:09:29+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-12-08T21:19:22+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=d9e2bec953880ecb5953b61b36a5beaec0565e22"/>
<id>urn:sha1:d9e2bec953880ecb5953b61b36a5beaec0565e22</id>
<content type="text"> The tvix-eval project is independent from any *uses* of the evaluator, such as the tvix-repl. This functionality has been split out into a separate "tvix-cli" crate. Note that this doesn't have to mean that this CLI crate is the "final" CLI crate for tvix, the point of this is not "getting the CLI structure right" but rather "getting the evaluator structure right". This reshuffling is part of restructuring the way that functionality like store communication is injected into language evaluation. Note that at this commit the new CLI crate is not at feature-parity. Change-Id: Id0af03dc8e07ef09a9f882a89612ad555eca8f93 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7541 Autosubmit: tazjin <tazjin@tvl.su> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI </content>
</entry>
<entry>
<title>feat(tvix/eval): add --raw flag to eval, like cppnix</title>
<updated>2022-11-26T21:20:02+00:00</updated>
<author>
<name>Adam Joseph</name>
<email>adam@westernsemico.com</email>
</author>
<published>2022-11-25T22:47:39+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=b5a1b965a6892d35b06ab315a531c718e02cd267"/>
<id>urn:sha1:b5a1b965a6892d35b06ab315a531c718e02cd267</id>
<content type="text"> Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: If07250a45fdf65a3f22ed8c37d7f37b45edccde9 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7416 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> </content>
</entry>
<entry>
<title>feat(tvix/eval): builtins.import without RefCell</title>
<updated>2022-10-27T21:36:01+00:00</updated>
<author>
<name>Adam Joseph</name>
<email>adam@westernsemico.com</email>
</author>
<published>2022-10-26T12:16:04+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=8616f13a71e3fc186e01bdb4ada60503f233be99"/>
<id>urn:sha1:8616f13a71e3fc186e01bdb4ada60503f233be99</id>
<content type="text"> CL/6867 added support for builtins.import, which required a cyclic reference import->globals->builtins->import. This was implemented using a RefCell, which makes it possible to mutate the builtins during evaluation. The commit message for CL/6867 expressed a desire to eliminate this possibility: This opens up a potentially dangerous footgun in which we could mutate the builtins at runtime leading to different compiler invocations seeing different builtins, so it'd be nice to have some kind of "finalised" status for them or some such, but I'm not sure how to represent that atm. This CL replaces the RefCell with Rc::new_cyclic(), making the globals/builtins immutable once again. At VM runtime (once opcodes start executing) everything is the same as before this CL, except that the Rc<RefCell<>> introduced by CL/6867 is turned into an rc::Weak<>. The function passed to Rc::new_cyclic works very similarly to overlays in nixpkgs: a function takes its own result as an argument. However instead of laziness "breaking the cycle", Rust's Rc::new_cyclic() instead uses an rc::Weak. This is done to prevent memory leaks rather than divergence. This CL also resolves the following TODO from CL/6867: // TODO: encapsulate this import weirdness in builtins The main disadvantage of this CL is the fact that the VM now must ensure that it holds a strong reference to the globals while a program is executing; failure to do so will cause a panic when the weak reference in the builtins is upgrade()d. In theory it should be possible to create strong reference cycles the same way Rc::new_cyclic() creates weak cycles, but these cycles would cause a permanent memory leak -- without either an rc::Weak or RefCell there is no way to break the cycle. At some point we will have to implement some form of cycle collection; whatever library we choose for that purpose is likely to provide an "immutable strong reference cycle" primitive similar to Rc::new_cyclic(), and we should be able to simply drop it in. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: I34bb5821628eb97e426bdb880b02e2097402adb7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7097 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> </content>
</entry>
<entry>
<title>feat(tvix/eval): add an AST pretty-printing module</title>
<updated>2022-10-16T12:26:56+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-10-13T12:23:45+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=0abc66ad91b8bcc25aeb7f3d086fcc52529ec8e8"/>
<id>urn:sha1:0abc66ad91b8bcc25aeb7f3d086fcc52529ec8e8</id>
<content type="text"> This implements serde::Serialize for the rnix AST through a wrapper type, and exposes a function for serialising the AST into a (pretty-printed JSON) string representation. This can be used to debug issues with the AST, and to display an AST reprsentation in tools like tvixbolt. Serialize is implemented manually because we don't own any of the structs and the way to traverse them is not easily derived automatically, and this is quite verbose. We might be able to condense it a little bit, but at the same time it's also fairly straightforward. Change-Id: I922df43cfc25636f3c8baee7944c75ade516055c Reviewed-on: https://cl.tvl.fyi/c/depot/+/6943 Autosubmit: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI Reviewed-by: Adam Joseph <adam@westernsemico.com> Reviewed-by: tazjin <tazjin@tvl.su> </content>
</entry>
<entry>
<title>feat(tvix/eval): allow to disable warnings</title>
<updated>2022-10-13T02:49:59+00:00</updated>
<author>
<name>Adam Joseph</name>
<email>adam@westernsemico.com</email>
</author>
<published>2022-10-12T06:18:25+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=e83609a06195642f472b112ffa95f001fde8ef60"/>
<id>urn:sha1:e83609a06195642f472b112ffa95f001fde8ef60</id>
<content type="text"> The nix_tests test suite produces lots of warnings. We can't fix these, since they are kept in sync with upstream, so there's little point in cluttering up the console with them every time the tests are run. Let's add a clap flag "warnings" and TVIX_WARNINGS environment variable. The default is "true". The test runner overrides this default and mutes the warnings. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: I4b065f96fe15838afcca6970491a54e248ae4df7 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6985 Reviewed-by: tazjin <tazjin@tvl.su> Reviewed-by: grfn <grfn@gws.fyi> Tested-by: BuildkiteCI </content>
</entry>
<entry>
<title>refactor(tvix/eval) s/NixPath/NixSearchPath/</title>
<updated>2022-10-12T08:09:49+00:00</updated>
<author>
<name>Adam Joseph</name>
<email>adam@westernsemico.com</email>
</author>
<published>2022-10-10T18:43:51+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=32ac7d6c6d06b5191fcc828b762b247b0e27dfda"/>
<id>urn:sha1:32ac7d6c6d06b5191fcc828b762b247b0e27dfda</id>
<content type="text"> Since NixString is the Rust type for nix strings, people might mistake NixPath for the Rust type of nix paths, which it is not. Let's call it NixSearchPath instead. Signed-off-by: Adam Joseph <adam@westernsemico.com> Change-Id: Ib2ea155c4b27cb90d6180a04ea7b951d86607373 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6927 Reviewed-by: kanepyork <rikingcoding@gmail.com> Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su> </content>
</entry>
<entry>
<title>feat(tvix/eval): Initial resolution of `<...>` paths</title>
<updated>2022-10-10T20:23:41+00:00</updated>
<author>
<name>Griffin Smith</name>
<email>root@gws.fyi</email>
</author>
<published>2022-10-10T03:46:51+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=273ba73754e9b10f768830d5a6835bf3d14e0d8a"/>
<id>urn:sha1:273ba73754e9b10f768830d5a6835bf3d14e0d8a</id>
<content type="text"> This commit implements (lazy) resolution of `<...>` paths via either the NIX_PATH environment variable, or the -I command-line flag - both handled via EvalOptions. As a result, EvalOptions can no longer derive Copy, meaning we have to clone it at each line of the repl - this is probably not a huge deal as repl performance is not exactly an inner loop and we're not cloning very much. Internally, this works by creating a thunk which pushes a constant containing the string inside the brackets to the stack, then a new opcode to resolve that path via the `NixPath`. To get that opcode to work, we now have to pass in the NixPath when constructing the VM. This (intentionally) leaves out proper implementation of path resolution via `findFile` (cppnix just calls whatever identifier called findFile is in scope!!!) as that's widely considered a bit of a misfeature, but if we do decide to implement that down the road it likely wouldn't be more than a few extra ops within the thunk introduced here. Change-Id: Ibc979b7e425b65cbe88599940520239a4a10cee2 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6918 Autosubmit: grfn <grfn@gws.fyi> Reviewed-by: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI </content>
</entry>
<entry>
<title>feat(tvix/eval): fancy-format parse errors returned by rnix</title>
<updated>2022-10-08T17:27:57+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-10-06T14:22:17+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=1e2d323a7c5b554f69902987b57c9d47d57e7eea"/>
<id>urn:sha1:1e2d323a7c5b554f69902987b57c9d47d57e7eea</id>
<content type="text"> This change is quite verbose, so a little bit of explaining: 1. To correctly format parse errors, errors must be able to return more than one annotated span (the parser returns a list of errors for each span). To accomplish this, the structure of how the `Diagnostic` struct which formats an error is constructed has changed to delegate the creation of the `SpanLabel` vector to the kind of error. 2. The rnix structures don't have human-readable output formats by default, so some verbose methods for formatting them in human-readable ways have been added in the errors module. We might want to move these out into a submodule. 3. In many cases, the errors returned by rnix are a bit strange - so while we format them with all information that is easily available they may look weird or not necessarily help users. Consider this CL only a first step in the right direction. Change-Id: Ie7dd74751af9e7ecb35d751f8b087aae5ae6e2e8 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6871 Reviewed-by: sterni <sternenseemann@systemli.org> Autosubmit: tazjin <tazjin@tvl.su> Tested-by: BuildkiteCI </content>
</entry>
<entry>
<title>feat(tvix/eval): add method for emitting runtime warnings</title>
<updated>2022-10-07T14:24:36+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-10-05T14:01:07+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=07e03498f26afbf647102d656c90d447f8586820"/>
<id>urn:sha1:07e03498f26afbf647102d656c90d447f8586820</id>
<content type="text"> This lets the VM emit warnings when it encounters situations that should only be warned about at runtime. For starters, this is used to pass through compilation warnings that come up when `import` is used. Change-Id: I0c4bc8c534d699999887c430d93629fadfa662c4 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6868 Reviewed-by: sterni <sternenseemann@systemli.org> Tested-by: BuildkiteCI </content>
</entry>
<entry>
<title>feat(tvix/eval): insert `import` into the builtins itself</title>
<updated>2022-10-07T14:24:36+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-10-04T20:58:21+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=4b9178fa2ae4cab718225f6136791df1d11814ee"/>
<id>urn:sha1:4b9178fa2ae4cab718225f6136791df1d11814ee</id>
<content type="text"> Adding `import` to builtins causes causes a bootstrap cycle because the `import` builtin needs to be initialised with the set of globals before being inserted into the globals, which also must contain itself. To break out of the cycle this hack wraps the builtins passed to the compiler in an `Rc` (probably sensible anyways, as they will end up getting cloned a bunch), containing a RefCell which gives us mutable access to the builtins. This opens up a potentially dangerous footgun in which we could mutate the builtins at runtime leading to different compiler invocations seeing different builtins, so it'd be nice to have some kind of "finalised" status for them or some such, but I'm not sure how to represent that atm. Change-Id: I25f8d4d2a7e8472d401c8ba2f4bbf9d86ab2abcb Reviewed-on: https://cl.tvl.fyi/c/depot/+/6867 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi> </content>
</entry>
</feed>