The target abi can also be set in build.zig via LibExeObjStep.target_abi
The value passed in is checked that it is a valid value in
std.Target.TargetAbi
The target abi is also validated against the target cpu
I'm working on a build.zig file where I'm leveraging InstallRawStep but I'd like to change the install dir. This allows the install dir to be changd and also enhances InstallRawStep to add more options in the future by putting them into a struct with default values. This also removes the need for an extra addInstallStepWithFormat function in build.zig.
`getExternalExecutor` is moved from `std.zig.CrossTarget` to
`std.zig.system.NativeTargetInfo.getExternalExecutor`.
The function also now communicates a bit more information about *why*
the host is unable to execute a binary. The CLI is updated to report
this information in a useful manner.
`getExternalExecutor` is also improved to detect such patterns as:
* x86_64 is able to execute x86 binaries
* aarch64 is able to execute arm binaries
* etc.
Added qemu-hexagon support to `getExternalExecutor`.
`std.Target.canExecBinaries` of is removed; callers should use the more
powerful `getExternalExecutor` instead.
Now that `zig test` tries to run the resulting binary no matter what,
this commit has a follow-up change to the build system and docgen to
utilize the `getExternalExecutor` function and pass `--test-no-exec`
in some cases to avoid getting the error.
Additionally:
* refactor: extract NativePaths and NativeTargetInfo into their own
files named after the structs.
* small improvement to langref to reduce the complexity of the `callconv`
expression in a couple examples.
Previously when using `zig run` or `zig test`, zig would try to guess
whether the host system was capable of running the target binaries. Now,
it will always try. If it fails, then Zig emits a helpful warning to
explain the probable cause.
from zig-specific options to generally recognized zig build options that
any project can take advantage of. See the updated usage text for more
details.
dd62a6d2e8de522187fd096354e7156cca1821c5 short-circuited the logic of
`asmExpr` by emitting ZIR for `@compileError("...")`. This caused false
positive "unreachable code" errors for stage1 when there was an
expression in the asm template.
This commit makes such cases instead go through logic of `asmExpr` like
normal, however the asm template is set to 0. This is then picked up in
Sema (part of stage2, not stage1) and reported as "assembly code must
use string literal syntax".
The old test "timeout_link_chain1" was ported from liburing test_timeout_link_chain1
509873c445/test/link-timeout.c (L539-L628)
However it turns out that both fails with EBADF (-9) on Linux kernel 5.4.
The this new test skips properly on Linux kernel 5.4
and passes on Linux kernel 5.11.
- use Bit Twiddling Hacks: Compute parity in parallel
- test cases derived from popcount.zig
- tests: compare naive approach 10_000 times with random numbers created
from naive seed 42
- compiler_rt.zig: sort by LLVM builtin order and add comments to improve structure
See #1290
The end-game for inline assembly is that the syntax is more integrated
with zig, and it will not allow string concatenation for the assembler
code, for the same reasons that Zig does not have a preprocessor.
However, inline assembly in zig right now is lacking for a variety of
use cases (take a look at the open issues having to do with inline
assembly for example), and being able to use comptime expressions to
concatenate text is a workaround that real-world users are exploiting to
get by in the short term.
This commit keeps "assembly code must use string literal syntax" as a
compile error when using stage2, but allows it through when using
stage1.
I expect to revert this commit after making enough improvements to
inline assembly that our real world users' needs are satisfied.
Previously there was only `--single-threaded`.
This flag now matches other boolean flags, instead of only being able to
opt in to single-threaded builds, you can now force multi-threaded
builds. Currently this only has the possibility to emit an error
message, but it is a better user experience to understand why one cannot
choose to enable threads in some cases.
This is breaking change to the CLI.
Related: #10143
The INVAL error was marked unreachable which prevents handling
of the error at a higher level.
It seems like it should map to BadPathError based on the man page for
rmdir (and an incomplete understanding of DeleteDirError), which says:
```
EINVAL pathname has . as last component.
```
This mostly reverts commit 692c254336da71cbe21aaf9fbc21240fd1269b95.
The test "for loop over pointers to struct, getting field from struct
pointer" is still failing on the CI so that one is not moved over.
similar commit from the past:
c73cd05468fba4bba5762a654aacdd9d90ecd272
This also modifies tools/update-linux-headers.zig to remove these same
files for next time to prevent a regression.
closes#10249
I don't think we can guarantee that especially for system dyld
dylibs which can be loaded at any address (perhaps even some
OS preferential low memory address).
Incidentally, this fixes stack trace tests on x86_64 macOS 12.
In order to be linker-independent, when parsing debug info in each
linked OSO, we also create a quick lookup table for symbols defined
within the OSO. We then use this lookup to map symbol from the EXE
to its defined address within the original OSO which we can then
use to extract its associated DWARF info (if any).
