Closed
Description
Prior to #108905, compiletest would take TARGET_RUSTCFLAGS
into account when determining whether a test target can unwind. It did so by calling rustc --print=cfg --target=$TARGET $TARGET_RUSTCFLAGS
, which changes the reported panic strategy depending on the flags:
$ rustc --print=cfg --target=x86_64-unknown-fuchsia
...
panic="unwind"
...
$ rustc --print=cfg --target=x86_64-unknown-fuchsia -Cpanic=abort
...
panic="abort"
...
After the PR, compiletest calls rustc --print=all-target-specs-json -Zunstable-options
which always reports the default panic strategy for the target (even if TARGET_RUSTCFLAGS
are passed):
$ rustc --print=all-target-specs-json -Zunstable-options
...
"x86_64-unknown-fuchsia": {
... (note that no "panic-strategy" is specified, it defaults to "unwind")
}
...
$ rustc --print=all-target-specs-json -Zunstable-options -Cpanic=abort
...
"x86_64-unknown-fuchsia": {
... ("panic-strategy" is still not specified)
}
...
This causes a problem for us because we run the compiler test suite against a toolchain built with -Cpanic=abort
. Compiletest will run tests marked with // needs-unwind
even though they panic (and thus fail).
I see a few options for fixing this issue:
- Have
--print=all-target-specs-json
respect any additional flags passed. - Parse
target_rustcflags
specifically for-Cpanic=abort
and modify the return value ofConfig::can_unwind()
to take it into account. - Add some new configuration flags to compiletest to control panic strategy for the selected target.
cc @pietroalbini who authored the original PR