In cases where the now removed `preserve < w.end` branch was taken, some of the data in the buffer would never make it to logical sink. For example, in one of the newly added test cases where a buffer of 10 is filled with 9 bytes, and then `splatBytePreserve` is called with a preserve of 5 and a splat of 2, the 5 preserved bytes in the buffer would get memmoved to the front of the buffer in the `preserve < w.end` branch, clobbering the first 4 bytes (without any chance of them making it to the logical sink).
After this commit, `rebase` is called to allow the implementation to do the preservation while sending any relevant bytes to the logical sink in the process.
Addresses part of https://github.com/ziglang/zig/issues/24767
Supersedes https://github.com/ziglang/zig/pull/24875
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.
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.
`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.
Alex Rønne Petersen