Previously, when using `zig build -fincremental --watch some-run-step`,
if the binary initially builds fine but a future update introduces a
compile error, the old file system inputs of the `Step.Run`---containing
the executable file itself---would remain. This is a bug, because that
file *has* changed since the input was registered (due to incremental
compilation), and yet the `Run` step is not out-of-date because it was
skipped due to a transitive failure.
A simple reproduction for this issue was:
$ zig init
$ zig build test --watch -fincremental
Then, in another terminal, introduce a compile error:
$ sed -i 's/const/onst/' src/main.zig
Before this commit, this would cause the `zig build` command to repeat
updates forever, separated only by the 50ms debounce interval.
To fix this, when we reset a step with intent to re-run it, we should
clear its inputs immediately, so that if the step is skipped, it is
correctly marked as having no inputs.
This relates to a more general problem with the file system watching
logic which is that the set of inputs includes files in the cache which
are actually artifacts of other steps. Eventually, the build system
should learn to identify such files and exclude them from the set of
file system inputs. In other words, the fact that a `Run` step depends
on the executable generated by a `Compile` step should be modeled by a
dependency in the build step graph, *not* by a dependency on the path
where the `Compile` step happens to have emitted its executable file.
Fixes a regression where this conversion crashes. When the conversion was
still possible it would produce a slice with a length of zero, which doesn't
really make a lot of sense either. There's no way to determine the length
of the destination slice from a pointer to an opaque type, so it's a compile
error now. Users should just cast to a many-item pointer and slice to the
desired length manually instead.
The host machine for the VMs we have is oversubscribed. There's not currently
much that can be done about that, but a hardware upgrade is planned for later
this year.
These are the last PowerPC cross targets that still use the IBM 128-bit long
double format. I'm not convinced anyone cares enough about them to justify
keeping them around, so this drops support. powerpc-linux-musleabi(hf), which
use the IEEE format, are still fully supported for people who want to use old
32-bit PowerPC hardware.
setKey used to just call rebuildIndex which allocates a new index and
inserts into it all entries. This is the only allocation that setKey
needed to do.
Instead I propose that setKey sets the key in the entries and then does
a remove of the old key from the index and insert of the new key into
the index. This eliminates the need for setKey to allocate and makes
it infallible
To achieve this I extracted a helper function for inserting a single
entry into the index. Function for removing one entry from the index
already exists. setKey now just calls these two functions.
Since `packed` containers are now internally represented by a `bitpack`,
they need special handling on initialization: they need to be either
bitpacked or bitcasted to their backing integer. `Sema` already did this,
but `LowerZon` didn't yet.
`HINSTANCE` is `*opaque {}` so using a type that should be compatible from alternate bindings (zigwin32, for example) would be a (false positive) compile error without this ptrCast.
Largely mirrors Haiku, Serenity provides crt0 and GCC the rest (though
only crtbegin/crtend are used as per serenity's toolchain patches[1]):
```
$ find Build/aarch64/Root -iname 'crt*.o'
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtbeginS.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtend.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtbegin.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtfastmath.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crti.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtn.o
Build/aarch64/Root/usr/local/lib/gcc/aarch64-serenity/15.2.0/crtendS.o
Build/aarch64/Root/usr/lib/crt0.o
```
Serenity has a GCC and LLVM toolchain that work equally well, support
for the latter may be added in the future.
[1]: https://github.com/SerenityOS/serenity/blob/727c4a3d1a6748221b383207dac354e564b6150d/Toolchain/Patches/gcc/0001-Add-a-gcc-driver-for-SerenityOS.patch#L120-L127
This PR merges the functionality of the `getLastOrNull` method into `getLast`, which improves consistency as its
based on methods like `front`, `back`, and `peek` in the `Deque` and `PriorityQueue` containers.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/32008
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Alex Rønne Petersen