Previously, if multiple navs owned the same type due to being the same
zir node and having the same captures, they would overwrite each other.
Now, the navs codegenned later emit a decl alias to the first one.
This code was left over from the legacy Autodoc implementation. No
component of the compiler pipeline actually requires doc comments, so it
is a waste of time and space to store them in ZIR.
This is, at least today, a very broken target: It doesn't actually build either
musl or wasi-libc even if you use -lc. It does give you musl headers, but that's
it. Those headers are not terribly useful, however, without any implementation
code. You can sort of call some math functions because they just so happen to
have implementations in compiler-rt. But that's only true for a small subset,
and I don't think users should be relying on the ABI surface of a library that
is an implementation detail of the compiler.
Clearly, a freestanding-capable libc of sorts is a useful thing as evidenced by
newlib, picolibc, etc existing. However, calling it "musl" is misleading when it
isn't actually musl-compatible, nor can it ever be because the musl API surface
is inextricably tied to the Linux kernel. In the discussion on #20690, there was
agreement that once we split up the API and ABI components in the target string,
the API component should be about compatibility, not whether you literally get a
particular implementation of it. Also, we decided that Linux musl and wasi-libc
musl shouldn't use the same API tag precisely because they're not actually
compatible.
(And besides, how would any syscall even be implemented in freestanding? Who or
what would we be calling?)
So I think we should remove this triple for now. If we decide to reintroduce
something like this, especially once #2879 gets going, we should come up with a
bespoke name for it rather than using "musl".
The goal of this commit is to get rid of some "unused command line argument"
warnings that Clang would give for various file types previously. This cleanup
also has the side effect of making the order of flags more understandable,
especially as it pertains to include paths.
Since a lot of code was shuffled around in this commit, I recommend reviewing
the old and new versions of the function side-by-side rather than trying to make
sense of the diff.
There are several test decls inside `/src` that are not currently being
tested and have bitrotted as a result. This commit revives those tests
and adds the `test-compiler-internals` set of tests which tests
everything reachable from `/src/main.zig`.
