mlugg

OP here---I think you got confused somewhere, because this isn't true! The hashes we take are of source code, they're just stored inside of the first IR. Source code is just pretty convenient to hash. If the change does turn out to be something trivial, we'll only invalidate the first-order dependencies of the source hash, which is never usually a big deal. In a particularly bad case, maybe we re-analyze, re-codegen, and re-link many different instances of a generic function, but even that wouldn't usually take long at all.

Also, it's actually important that we do notice these kinds of "trivial" changes in some parts of the pipeline---see Andrew's comment [0] on the Lobsters discussion for this post.

Right now, yep, corrupting the binary that the compiler reads would crash the compiler. In future, we want to detect the corruption and force a clean build. Note however that the Zig compiler is writing the binary to its internal cache directory (typically `.zig-cache/`), and the build system then copies the final artifact to your output ("prefix") directory (`zig-out/` by default), so it doesn't matter if the user messes with the final binary in `zig-out/bin/my_program`, because that's just a copy. Lastly, this is not implemented yet, but we will definitely make sure that Ctrl+C leave the cache in a clean state. I'm pretty sure our incremental compilation system has a nice property that you can just cancel an update partway through and continue it later without too much effort. See also Zig's IO interface [0] for information about cancelation. The compiler should already support graceful-ish cancelation internally (I won't claim to have verified this, because we never actually do cancel compilation right now, but I'm not aware of any glaring issues!). I don't think it'd be a crazy amount of work to improve that so that it also leaves incremental compilation in a valid state.

(To be clear, squeek502 is a part of the Zig core team [0], so he knows what he's talking about :D)

What do you mean by "interim"? As I explicitly stated in the comment you quoted, it has never, and likely will never, been planned for the Zig compiler to become incapable of using LLVM. The LLVM backend still sees plenty of active development by the core team [0]---that's perfectly compatible with improving the experience of users (including ourselves) by avoiding unnecessary uses of LLVM [1].

> ...is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.

I think you are incorrectly assuming that we currently make heavy use of the LLVM API. As indicated by #13265 being closed, that is not true. The Zig compiler already generates bitcode by itself, without touching the LLVM API. The only thing we actually use the LLVM API for is feeding that bitcode to LLVM, which can easily be done by invoking a CLI instead. Users quite literally would not be able to tell if, for instance, we changed the compiler to pass the bitcode to Zig's embedded build of Clang over CLI.

Hm, are you referring to the CI failure on the x86_64-linux-release CI job on the current tip of master on the main Zig repository? That one's a flaky test, not indicative of a serious problem. (We usually just disable flaky tests, but this particular one I'm leaving on for the moment to try and gather a little more information about it.)