further reduce bootstrapping dependencies by making stage1 output C rather than LLVM IR

[andrewrk]

Related but different: #3772

This issue is to delete the Clang, LLVM, and LLD dependencies of stage1. It will make it possible to bootstrap a fully self-hosted zig without ever touching the LLVM project.

This issue depends on the self-hosted compiler being completely done (#89).

Further, the next step after that will be to stop using C++ features in stage1, making it pure C, with no dependency on a C++ compiler or libc++.

The self-hosted Zig compiler will have an optional dependency on Clang, LLVM, and LLD. The bootstrapping process will look like the following, if this issue is implemented:

• Use system C compiler to compile .c source files into zig1 executable
• Use zig1 executable to compile .zig source files into .c generated files
• Use system C compiler to compile .c source files + generated .c files into zig2 executable
• Use zig2 executable to compile .zig source files into zig executable

Any further recompiling of zig would yield the same binary. E.g. using the final zig executable to compile the .zig source files would result in the same zig executable.

On the final step it would be possible to select any desired target (cross compiling) as well as selecting the option of enabling LLVM features.

[Rocknest]

Will stage2 be able to output c code? Will then stage1 source be autogenerated from stage2 source? What about cImport? That feature is core zig and depends on clang, right? If clang was optional then cImport would be downgraded to second-class feature.

[andrewrk]

Will stage2 be able to output c code?

#3772

Will then stage1 source be autogenerated from stage2 source?

No, see the discussion on #853

What about cImport?

cimport, translate-c, zig cc features as well as additional target support are unlocked when the optional LLVM/Clang/LLD dependencies are enabled.

If clang was optional then cImport would be downgraded to second-class feature.

The C extensions to zig have always been planned to be an optional extension to the language in the specification, and likewise the c compiler toolchain features is not a required part of a conforming zig compiler.

[mikdusan]

cimport, translate-c, zig cc features as well as additional target support are unlocked when

I thought we could unlock these features with Z-Bucks 😉

[wizzard0]

hmm, speaking of "minimalistic self-contained toolchain", I think it makes sense to also consider TCC (Bellard's Tiny C Compiler) for at least some targets. Maybe some parts of TCC can also be repurposed for cImport?

[andrewrk]

The plan for this is now to, at some strategic moment, utilize the C backend of stage2 to do a one time thing where we delete stage1 and replace it with the C backend output of stage2. The reason this won't be problematic for bootstrapping (#853) is that we won't keep doing it. The new stage1 C code will then get manually cleaned up and reorganized, and start being manually maintained to keep up with stage2, therefore granting it "source" status rather than "generated file" status.

[tauoverpi]

Having a zig interpreter (AST-based or similar) written in C that's just enough to run stage2 could also work and would satisfy the bootstrap requirement while avoiding the issues of the number of instances generated by generics. This would then make it c compiler -> interpreter -> stage2 -> stage3 at the cost of likely being slower but I think the lower complexity in maintaining it would be worth it.