This regressed back in https://github.com/ziglang/zig/pull/25154. I
didn't get around to fixing it until now, so a few instances of the
warning snuck into the repo over the past few months, which were fixed
in the previous commit. The regression has not appeared in a tagged
release though, so this is not a breaking change in 0.16.0.
Resolves: https://codeberg.org/ziglang/zig/issues/31049
I've realised that the cause of at least some of our weird CI flakiness
was a bug in how `Nav` values were resolved. Consider this scenario: the
frontend resolves the type of a `Nav`, and then sends a function to the
backend, which requires the backend to lower a pointer to that `Nav`.
The backend calls `InternPool.getNav` to determine the `Nav`'s type.
However, this races with the frontend resolving the *value* of that
`Nav`. This involves writing separately to two fields, `bits` and
`type_or_value`. If only one of these changes is observed, then the
backend will incorrectly interpret the type as the value or vice versa,
leading to a crash or even a miscompilation. (Of course, there's also
the straightforward issue that the racing loads were non-atomic, making
them illegal).
The only good solution to this was to make `Nav` 4 bytes bigger, giving
it separate `type` and `value` fields. In theory that's a quite small
change, but it ended up having a bunch of nice consequences which led to
this diff being a bit bulkier than expected:
* `Nav.Repr.Bits` was simplified, because it no longer has to track
"resolution status": we can use `.none` for that. This frees up some
bits to make things more consistent between the "type resolved" and
"fully resolved" states.
* This consistency allowed the `Nav.status` union to be replaced with a
simpler field `Nav.resolved`, which is a bit nicer to work with.
* Most of the "getter" functions were able to be removed from `Nav`
because the state they were fetching had been moved to simple fields
on `Nav.resolved`.
* There were still a handful of free bits in `Nav.Repr.Bits`, which
could be used to represent the "const" and "threadlocal" flags rather
than these being stored on `Key.Extern` and `Key.Variable`. This is a
bit more convenient for linkers.
* With those bits gone, `Key.Variable` is a trivial wrapper around a
type and an initial value, and the fact that a declaration is mutable
can be represented solely through the "const" flag. Therefore,
`Key.Variable` no longer served a purpose, and could be eliminated
entirely in favour of storing the variable's initial value directly in
the "value" field of the `Nav`.
So, I'm quite pleased with this refactor! But anyway, regarding the bug
fix which actually motivated this: if I've done my job correctly, this
should solve some crashes, such as these (which were what tipped me off
to this bug in the first place):
https://codeberg.org/ziglang/zig/actions/runs/2306/jobs/7/attempt/1https://codeberg.org/ziglang/zig/actions/runs/2173/jobs/6/attempt/1
...and, who knows, perhaps even the random SIGSEGVs we've seen on some
targets! Probably not, but one can hope.
This commit removes `posix_fadvise`, `posix_fallocate`, and `fallocate`
from the bundled musl by forwarding to Zig's wrappers. `musl`'s
implemenation does not use `__syscall_cp`, so I assume trivially
replacing these functions is okay.
For `posix_fadvise`, `musl` notes that the arguments are reordered
for ARM and other architectures. Zig's wrapper already handles this
case.
Contributes toward: #30978
We can directly access this path string from the PEB (albeit with some
weirdness around addressing) and that ends up making the downstream code
simpler and more efficient. (Almost like the kernel32 API isn't very
good!)
BE32 is deprecated and only supported by older cores and some v6 cores. All
cores v6 or newer support BE8, so default to that for v6+.
closes https://codeberg.org/ziglang/zig/issues/31404
There were just too many bugs. This new implementation supports zig fmt:
on/off. It also puts expressions with unicode characters on their own
line, which avoids issues with aligning them.
Adds two new space modes maybe_space and comma_maybe_space which only
render the space when the next token is not a multiline string literal.
This is used in a lot of places to avoid a trailing space on lines
caused by multiline string literals forcing newlines.
Fixes places where the node tag is compared to be a multiline string
literal to instead check if the first token is a multiline string
literal line. This fixes cases like `\\ ++ text`.
This commit also rewrites quite a bit of code to be clearer /
deduplicated.
This fuzz test checks several properties of zig fmt are upheld, namely
idempotency, textual equivilence, and no trailing whitespace.
All functions in the fuzz test have @disableInstrumentation for
performance and since their branches are not interesting to the fuzzer.
My changes to how incremental compilation handles container types mean
that, at least for now, it is possible for the ZIR `.main_struct_inst`
of a source file to be lost (this happens if the number of top-level
fields in a file changes for instance). I missed a few things which
needed changing to account for this, which could lead to crashes with
certain (trivial) changes---oops!
Adds two new incremental test cases. They are currently disabled for
wasm32-wasi-selfhosted because they both trigger a crash in the WASM
backend.
This may be a breaking change for callers that depend on the return type
size being identical to the input. For example, `sign(i32) * i8 + i8`
could now overflow. Callers can add an explicit type annotation to avoid
that problem.
mlugg