What would second implementation of Zig need to compile/bootstrap Zig?

[squeek502]

Here’s @andrewrk’s answer:

@andrewrk

For the real world purposes of bootstrapping, the best solution is for a third party to implement a zig interpreter that assumes -target wasm32-wasi and uses pub const dev = .bootstrap; in the config options in order to produce zig2.c and continue the build from there. This interpreter could be written in Lua or Lisp for example, and only needs to be able to interpret exactly the latest tagged release of Zig. Any tricky one-off functions could be hacked around in this interpreter since it is a bespoke interpreter for this one codebase. Such hacks would not compromise the goal of the interpreter, which is to ensure that zig1.wasm has no hidden logic.

Some more details from the compiler development Zulip:

i.e. a bespoke interpreter for bootstrapping zig 0.13.0. and then when 0.14.0 comes out it gets updated to be able to interpret exactly that source

I bet such an interpreter could operate directly on AST

and it wouldn’t really have to differentiate between comptime and runtime

My attempt at clarifying after I continually misunderstood the idea:

• the end goal is for the interpreter to take the compiler source code and run it without the intermediate steps in the “zig → wasm → c → compile zig1 → run zig1” chain. In other words, running the interpreter on the compiler source code should basically do what the compiled zig1 does, and the expected output is actually the same as the zig1-generated zig2.c since it’s the result of running zig1
  • put another way, this is not a zig → c transpiler, that just happens to be the output when running zig1 with the arguments it’s passed
  • in other other words, an interpreter…
• so, for the hello world, the expected result is Hello World printed to stdout (as mentioned)