feat(tvix/eval): Initial resolution of `<...>` paths r/5087

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

1 files changed, 6 insertions, 0 deletions

diff --git a/tvix/eval/src/opcode.rs b/tvix/eval/src/opcode.rs
index 15f60a538c41..96234ccd233c 100644
--- a/tvix/eval/src/opcode.rs
+++ b/tvix/eval/src/opcode.rs
@@ -112,6 +112,12 @@ pub enum OpCode {
     /// `CoercionKind::Weak`.
     OpCoerceToString,
 
+    // Paths
+    /// Attempt to resolve the Value on the stack using the configured [`NixPath`][]
+    ///
+    /// [`NixPath`]: crate::nix_path::NixPath
+    OpFindFile,
+
     // Type assertion operators
     OpAssertBool,