Evaluate all child processes in the temporary directory, and use
`std.fs.path.relative` to make every other path relative to that child
cwd instead of our cwd.
Resolves: #22119
The real problem here is that Git for Windows has horrendous defaults
which convert LF to CRLF. However, rather than changing this
configuration on the CI runners, it's worth supporting inexplicable CRLF
in these files so that anyone else cloning Zig on Windows doesn't get
unexpected test failures.
Uses of `@embedFile` register dependencies on the corresponding
`Zcu.EmbedFile`. At the start of every update, we iterate all embedded
files and update them if necessary, and invalidate the dependencies if
they changed.
In order to properly integrate with the lazy analysis model, failed
embed files are now reported by the `AnalUnit` which actually used
`@embedFile`; the filesystem error is stored in the `Zcu.EmbedFile`.
An incremental test is added covering incremental updates to embedded
files, and I have verified locally that dependency invalidation is
working correctly.
This will mainly be used when targeting our wasm2c implementation which has no
problem with zero-length bulk memory operations, as a non-standard extension.
See: https://github.com/WebAssembly/tool-conventions/pull/235
This is not *quite* using the same features as the spec'd lime1 model because
LLVM 19 doesn't have the level of feature granularity that we need for that.
This will be fixed once we upgrade to LLVM 20.
Part of #21818.
The goal here is to support both levels of unwind tables (sync and async) in
zig cc and zig build. Previously, the LLVM backend always used async tables
while zig cc was partially influenced by whatever was Clang's default.
To my knowledge there isn't an implementation of `sse4.2` that doesn't have `crc32`.
The Clang driver also sets `crc32` to be implicitly enabled when an explicit `-crc32`
wasn't provided. This matches that behaviour.
We need this behaviour to compile libraries like `rocksdb` which currently guard against
`crc32` intrinsics by checking for `sse4.2`.
* Cleanup the argument handling logic to allow for optional arguments.
* Add a filter for which `llvm_target` to process.
* Switch to using a threadpool, needed for skipping llvm targets cleanly
and better distributes the work.
* Remove a seemingly useless piece of logic. I re-ran the script and it gave identical outputs.
The tool will now skip over undefined symbols. These can only occur as a result
of building musl without compiler-rt, i.e. -rtlib=none. Thanks to this, it's no
longer necessary to patch Zig's compiler-rt, nor is it necessary to maintain a
symbol blacklist.
See the updated instructions here: https://github.com/ziglang/zig/wiki/Updating-libc#updating-the-libcs-file
Additionally, the tool now produces slightly more compact output by recognizing
symbols that are defined for a single arch, for a family of arches, or only for
arches using 32-bit or 64-bit time as their primary ABI.
Finally, the tool now supports all architectures that we can emit code for, with
the single exception of x86_64-linux-muslx32. (x32 currently fails with a ton of
relocation errors, leading me to believe that it might be an LLVM or LLD bug.)
Like d1d95294fd657f771657ea671a6984b860347fb0, this is more Apple nonsense where
they abused the arch component of the triple to encode what's really an ABI.
Handling this correctly in Zig's target triple model would take quite a bit of
work. Fortunately, the last Armv7-based Apple Watch was released in 2017 and
these targets are now considered legacy. By the time Zig hits 1.0, they will be
a distant memory. So just remove them.
If no external executor is available for a successful binary, its
execution is silently skipped. This allows the CI to test, to the
fullest extent possible, incremental cross-compilation to targets whose
binaries can't be executed on the host.
This is contained in the `test` step, so is tested by CI.
This commit also includes some enhancements to the `incr-check` tool to
make this work correctly.
