Add perma-unstable --print=backend-has-zstd for use by compiletest
#149666
Conversation
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built without support for zstd compression. Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler.
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
rustbot
added
A-compiletest
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
|
You can r=me once PR CI is green. |
|
@bors r=jieyouxu |
bors
added
S-waiting-on-bors
Rollup of 11 pull requests Successful merges: - #148662 (alloc: Document panics when allocations will exceed max) - #148811 (core docs: rewrite `panic::Location::caller` with visual line/column numbers) - #149101 (Improve mutable-binding suggestion to include name) - #149477 (float::maximum/minimum: make docs more streamlined) - #149547 (library: Rename `IterRange*` to `Range*Iter`) - #149548 (Generate delegation error body when delegation is not resolved) - #149630 (Check identifiers defined in macros when suggesting identifiers hidden by hygiene) - #149647 (Add regression test for 141845) - #149661 (Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.) - #149666 (Add perma-unstable `--print=backend-has-zstd` for use by compiletest) - #149671 (interpret: test SNaN handling of float min/max and update comments) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #149666 - Zalathar:backend-has-zstd, r=jieyouxu Add perma-unstable `--print=backend-has-zstd` for use by compiletest Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built without support for zstd compression. Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler. --- Originally I was intending for this to be a `--print=debuginfo-compression` flag that would print out a list of values supported by `-Zdebuginfo-compression=`. I got that working locally, but it was more complex than I was happy with (in both rustc and compiletest), so I decided to cut scope and instead add a very narrow perma-unstable print request instead. There is always a circularity hazard whenever we ask the compiler-under-test for information about how to test it. But in this case, the underlying compiler code is fairly simple, whereas the previous heuristics were inherently messy and unreliable anyway.
Rollup of 11 pull requests Successful merges: - rust-lang/rust#148662 (alloc: Document panics when allocations will exceed max) - rust-lang/rust#148811 (core docs: rewrite `panic::Location::caller` with visual line/column numbers) - rust-lang/rust#149101 (Improve mutable-binding suggestion to include name) - rust-lang/rust#149477 (float::maximum/minimum: make docs more streamlined) - rust-lang/rust#149547 (library: Rename `IterRange*` to `Range*Iter`) - rust-lang/rust#149548 (Generate delegation error body when delegation is not resolved) - rust-lang/rust#149630 (Check identifiers defined in macros when suggesting identifiers hidden by hygiene) - rust-lang/rust#149647 (Add regression test for 141845) - rust-lang/rust#149661 (Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.) - rust-lang/rust#149666 (Add perma-unstable `--print=backend-has-zstd` for use by compiletest) - rust-lang/rust#149671 (interpret: test SNaN handling of float min/max and update comments) r? `@ghost` `@rustbot` modify labels: rollup
| PrintKind::BackendHasZstd => { | ||
| let has_zstd = llvm::LLVMRustLLVMHasZstdCompression(); | ||
| writeln!(out, "{has_zstd}").unwrap(); | ||
| } |
There was a problem hiding this comment.
There is no default implementation of this print request, which causes compiletest to break for all non-llvm backends unless they explicitly add an implementation for this.
There was a problem hiding this comment.
Oh, that's surprising, sorry.
I had intended to write this in a way that was friendly to other backends, but then I went back and changed things for other reasons and that property was lost.
There was a problem hiding this comment.
Worked around this on the cg_clif side for now. cg_gcc would also need changes.
There was a problem hiding this comment.
Does the failure only occur when a non-LLVM backend is the default? Or does it break even when LLVM is the default and a different backend is selected?
There was a problem hiding this comment.
My tentative fix is to add this to llvm_has_zstd in src/tools/compiletest/src/directives/needs.rs:
if !config.default_codegen_backend.is_llvm() {
return false;
}But I can't get any non-LLVM backends to work on my system at the moment, so I have no way to test this fix.
There was a problem hiding this comment.
Given that you don't pass -Zcodegen-backend even when the user selects a different codegen backend, this should right now only break when a non-LLVM codegen backend is the default.
There was a problem hiding this comment.
Yeah, that probably explains why it wasn't caught by CI.
I have a backend-agnostic fix posted at #149764.
6 participants
Tests for
-Zdebuginfo-compression=zstdneed to be skipped if LLVM was built without support for zstd compression.Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler.
Originally I was intending for this to be a
--print=debuginfo-compressionflag that would print out a list of values supported by-Zdebuginfo-compression=. I got that working locally, but it was more complex than I was happy with (in both rustc and compiletest), so I decided to cut scope and instead add a very narrow perma-unstable print request instead.There is always a circularity hazard whenever we ask the compiler-under-test for information about how to test it. But in this case, the underlying compiler code is fairly simple, whereas the previous heuristics were inherently messy and unreliable anyway.