feat(tvix/eval): insert `import` into the builtins itself r/5048

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>

1 files changed, 3 insertions, 1 deletions

diff --git a/corp/tvixbolt/src/main.rs b/corp/tvixbolt/src/main.rs
index a389a33f04ed..f81ae070a2ce 100644
--- a/corp/tvixbolt/src/main.rs
+++ b/corp/tvixbolt/src/main.rs
@@ -1,4 +1,6 @@
+use std::cell::RefCell;
 use std::fmt::Write;
+use std::rc::Rc;
 
 use serde::{Deserialize, Serialize};
 use tvix_eval::observer::TracingObserver;
@@ -256,7 +258,7 @@ fn eval(trace: bool, code: &str) -> Output {
         &root_expr,
         Some("/nixbolt".into()),
         file.clone(),
-        tvix_eval::global_builtins(),
+        Rc::new(RefCell::new(tvix_eval::global_builtins())),
         &mut compilation_observer,
     )
     .unwrap();