Skip to content

Compiletest no longer respects -Cpanic=abort in TARGET_RUSTCFLAGS after #108905 #110850

Closed

Description

@djkoloski

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 of Config::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

Activity

  1. jyn514 commented on Apr 26, 2023

    @jyn514
    Member

    Have --print=all-target-specs-json respect any additional flags passed.

    This seems like the best solution to me.

  2. added
    A-testsuiteArea: The testsuite used to check the correctness of rustc
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.
    on Apr 26, 2023
  3. added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Apr 26, 2023
  4. apiraino commented on Apr 27, 2023

    @apiraino
    Contributor

    WG-prioritization assigning priority (Zulip discussion).

    @rustbot label -I-prioritize +P-high

  5. added
    P-highHigh priority
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Apr 27, 2023
  6. emilyalbini commented on May 2, 2023

    @emilyalbini
    Member

    Agree with jyn here on the solution. Unfortunately I won't have much time myself in the coming weeks to address this :(

  7. added a commit that references this issue on May 15, 2023
    32e2883
  8. added a commit that references this issue on May 16, 2023
    72b2716
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-testsuiteArea: The testsuite used to check the correctness of rustcC-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions