diff options
| author | mlugg <mlugg@mlugg.co.uk> | 2025-08-15 20:49:34 +0100 |
|---|---|---|
| committer | Andrew Kelley <andrew@ziglang.org> | 2025-08-18 13:07:40 -0700 |
| commit | c1483eb05c221b4f0c0c357bf75b828f722fa44d (patch) | |
| tree | 81956e1fdf1b4effd44386f02759a042e274e0ab /lib/std/debug.zig | |
| parent | 2f422372b588789a5ce208bb85c9bfeee84dd980 (diff) | |
| download | zig-c1483eb05c221b4f0c0c357bf75b828f722fa44d.tar.gz zig-c1483eb05c221b4f0c0c357bf75b828f722fa44d.zip | |
Compilation: fix compiler_rt and ubsan_rt strategy logic
It doesn't really make sense for `target_util.canBuildLibCompilerRt`
(and its ubsan-rt friend) to take in `use_llvm`, because the caller
doesn't control that: they're just going to queue a sub-compilation for
the runtime. The only exception to that is the ZCU strategy, where we
effectively embed `_ = @import("compiler_rt")` into the Zig compilation:
there, the question does matter. Rather than trying to do multiple weird
calls to model this, just have `canBuildLibCompilerRt` return not just a
boolean, but also differentiate the self-hosted backend being capable of
building the library vs only LLVM being capable. Logic in `Compilation`
uses that difference to decide whether to use the ZCU strategy, and also
to disable the library if the compiler does not support LLVM and it is
required.
Also, remove a redundant check later on, when actually queuing jobs.
We've already checked that we can build `compiler_rt`, and
`compiler_rt_strat` is set accordingly. I'm guessing this was there to
work around a bug I saw in the old strategy assignment, where support
was ignored in some cases.
Resolves: #24623
Diffstat (limited to 'lib/std/debug.zig')
0 files changed, 0 insertions, 0 deletions
