This commit enhances AstGen to introduce a form of error resilience
which allows valid ZIR to be emitted even when AstGen errors occur.
When a non-fatal AstGen error (e.g. `appendErrorNode`) occurs, ZIR
generation is not affected; the error is added to `astgen.errors` and
ultimately to the errors stored in `extra`, but that doesn't stop us
getting valid ZIR. Fatal AstGen errors (e.g. `failNode`) are a bit
trickier. These errors return `error.AnalysisFail`, which is propagated
up the stack. In theory, any parent expression can catch this error and
handle it, continuing ZIR generation whilst throwing away whatever was
lost. For now, we only do this in one place: when creating declarations.
If a call to `fnDecl`, `comptimeDecl`, `globalVarDecl`, etc, returns
`error.AnalysisFail`, the `declaration` instruction is still created,
but its body simply contains the new `extended(astgen_error())`
instruction, which instructs Sema to terminate semantic analysis with a
transitive error. This means that a fatal AstGen error causes the
innermost declaration containing the error to fail, but the rest of the
file remains intact.
If a source file contains parse errors, or an `error.AnalysisFail`
happens when lowering the top-level struct (e.g. there is an error in
one of its fields, or a name has multiple declarations), then lowering
for the entire file fails. Alongside the existing `Zir.hasCompileErrors`
query, this commit introduces `Zir.loweringFailed`, which returns `true`
only in this case.
The end result here is that files with AstGen failures will almost
always still emit valid ZIR, and hence can undergo semantic analysis on
the parts of the file which are (from AstGen's perspective) valid. This
is a noteworthy improvement to UX, but the main motivation here is
actually incremental compilation. Previously, AstGen failures caused
lots of semantic analysis work to be thrown out, because all `AnalUnit`s
in the file required re-analysis so as to trigger necessary transitive
failures and remove stored compile errors which would no longer make
sense (because a fresh compilation of this code would not emit those
errors, as the units those errors applied to would fail sooner due to
referencing a failed file). Now, this case only applies when a file has
severe top-level errors, which is far less common than something like
having an unused variable.
Lastly, this commit changes a few errors in `AstGen` to become fatal
when they were previously non-fatal and vice versa. If there is still a
reasonable way to continue AstGen and lower to ZIR after an error, it is
non-fatal; otherwise, it is fatal. For instance, `comptime const`, while
redundant syntax, has a clear meaning we can lower; on the other hand,
using an undeclared identifer has no sane lowering, so must trigger a
fatal error.
It doesn't appear that targeting bridgeOS is meaningfully supported by Apple.
Even LLVM/Clang appear to have incomplete support for it, suggesting that Apple
never bothered to upstream that support. So there's really no sense in us
pretending to support this.
The freestanding and other OS targets by default need to just @trap in the
default Panic implementation.
And `isValidMemory` won't work with freestanding or other targets.
Update the unwind_freestanding.zig test case to also run on the 'other' OS
target, too. This should keep the Zig's stacktrace generation from
regressing on the standalone targets.
Without doing this, we don't actually test whether the data layout string we
generate matches LLVM's.
A number of targets had to be commented out due to this change:
* Some are using a non-working experimental LLVM backend (arc, csky, ...).
* Some don't have working LLD support (lanai, sparc, ...).
* Some don't have working self-hosted linker support (nvptx).
* Some are using ABIs that haven't been standardized (loongarch32).
Finally, all non-x86 uefi targets are hopelessly broken and can't really be
fixed until we change our emit logic to lower *-uefi-* verbatim rather than to
*-windows-*. See: https://github.com/ziglang/zig/issues/21630
Previously, stepping from the single statement within the loop would
always exit the loop because all of the code unrolled from the loop is
associated with the same line and treated by the debugger as one line.
/home/alexrp/.cache/zig/b/18236e302af25e3fb99bc6a232ddc447/builtin.zig:6:5: error: TODO (SPIR-V): Implement unsigned composite int type of 64 bits
pub const zig_backend = std.builtin.CompilerBackend.stage2_spirv64;
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is necessary since isGnuLibC() is true for hurd, so we need to be able to
represent a glibc version for it.
Also add an Os.TaggedVersionRange.gnuLibCVersion() convenience function.
This is similar to the old `llvm/shift_right_plus_left` case, which was
disabled by 1b1c78c. The case is not enabled on the LLVM backend, since
incremental compilation support for this backend is a work in progress
and is tracked by #21165. It passes on the x86_64-linux target with the
self-hosted backend.
Resolves: #12288
These cases have been disabled for a while, and we have transitioned to
using a compact file format for incremental test cases.
I was originally planning to port all of these cases, but the vast
majority aren't testing anything interesting, so it wasn't worth the
effort. I did look through each one; anything interesting being tested
has been extracted into a new case in `test/incremental/`.
Two of the new tests are currently failing with the self-hosted ELF
linker, and thus are currently only enabled with the C backend.
Resolves: #12844
The old isARM() function was a portability trap. With the name it had, it seemed
like the obviously correct function to use, but it didn't include Thumb. In the
vast majority of cases where someone wants to ask "is the target Arm?", Thumb
*should* be included.
There are exactly 3 cases in the codebase where we do actually need to exclude
Thumb, although one of those is in Aro and mirrors a check in Clang that is
itself likely a bug. These rare cases can just add an extra isThumb() check.
Once we upgrade to LLVM 20, these should be lowered verbatim rather than to
simply musl. Similarly, the special case in llvmMachineAbi() should go away.
