-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No branch protection metadata unless enabled #93516
Conversation
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
afcfc62
to
74fedfe
Compare
This comment has been minimized.
This comment has been minimized.
74fedfe
to
b67bac8
Compare
Could you also add a test that branch protection does not run when not explicitly enabled? |
I think that should covered by the
What do you mean? |
To add context, |
b67bac8
to
e522813
Compare
This comment has been minimized.
This comment has been minimized.
e522813
to
7845d16
Compare
☔ The latest upstream changes (presumably #94121) made this pull request unmergeable. Please resolve the merge conflicts. |
Nominating for beta since this missed the beta cut-off. |
7845d16
to
4ae6a2e
Compare
This comment has been minimized.
This comment has been minimized.
Even if we emit metadata disabling branch protection, this metadata may conflict with other modules (e.g. during LTO) that have different branch protection metadata set. This is an unstable flag and feature, so ideally the flag not being specified should act as if the feature wasn't implemented in the first place. Additionally this PR also ensures we emit an error if `-Zbranch-protection` is set on targets other than the supported aarch64. For now the error is being output from codegen, but ideally it should be moved to earlier in the pipeline before stabilization.
4ae6a2e
to
b995dc9
Compare
(Note: I believe the beta being referenced here is 1.60, not 1.59 which is shipping later this week). |
@bors r+ rollup=never |
📌 Commit b995dc9 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (761e888): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
No branch protection metadata unless enabled Even if we emit metadata disabling branch protection, this metadata may conflict with other modules (e.g. during LTO) that have different branch protection metadata set. This is an unstable flag and feature, so ideally the flag not being specified should act as if the feature wasn't implemented in the first place. Additionally this PR also ensures we emit an error if `-Zbranch-protection` is set on targets other than the supported aarch64. For now the error is being output from codegen, but ideally it should be moved to earlier in the pipeline before stabilization.
[beta] Beta backports * No branch protection metadata unless enabled rust-lang#93516 * update auto trait lint for PhantomData rust-lang#94315 * Cargo: * [1.60] Fix term.verbose without quiet, and vice versa (rust-lang/cargo#10436) * [beta] Add common profile validation. (rust-lang/cargo#10413) * Avoid new deprecation warnings from clap 3.1.0 (rust-lang/cargo#10396)
…=nagisa Check AArch64 branch-protection earlier in the pipeline. As suggested in rust-lang#93516. r? `@nagisa`
…=nagisa Check AArch64 branch-protection earlier in the pipeline. As suggested in rust-lang#93516. r? `@nagisa`
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.
This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.
Additionally this PR also ensures we emit an error if
-Zbranch-protection
is set on targets other than the supportedaarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.