Skip to content

Conversation

@arielb1
Copy link
Contributor

@arielb1 arielb1 commented Nov 26, 2025

This implements -Z allow-partial-mitigations as an unstable option, currently with support for control-flow-guard and stack-protector.

As a difference from the RFC, we have -Z allow-partial-mitigations=!foo rather than -Z deny-partial-mitigations=foo, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.

To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).

r? @rcvalle

@rustbot
Copy link
Collaborator

rustbot commented Nov 26, 2025

These commits modify compiler targets.
(See the Target Tier Policy.)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 26, 2025
@rust-log-analyzer

This comment has been minimized.

metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diagnostics must always start with a lowercase letter.

Suggested change
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
.note = recompile that `{$extern_crate}` with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled

metadata_mitigation_less_strict_in_dependency =
your program uses the crate `{$extern_crate}`, that is not protected by `{$mitigation_name}{$mitigation_level}`
.note = Recompile that crate with the mitigation enabled, or use `-Z allow-partial-mitigations={$mitigation_name}` to allow creating an artifact that has the mitigation only partially enabled
.help = It is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.help = It is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`
.help = it is possible to disable `-Z allow-partial-mitigations={$mitigation_name}` via `-Z allow-partial-mitigations=!{$mitigation_name}`

@Urgau
Copy link
Member

Urgau commented Nov 26, 2025

To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).

I don't think we currently have any command line arguments who is edition depended, that would be a first.

@arielb1
Copy link
Contributor Author

arielb1 commented Nov 26, 2025

I don't think we currently have any command line arguments who is edition depended, that would be a first.

The behavior for -C control-flow-guard is in the RFC. Tho that RFC is not approved yet.

I do think we want to eventually make -C control-flow-guard enforcing, and I think we have to do that across an edition boundary.

Some(s) => {
for sub in s.split(',') {
let (sub, enabled) =
if sub.starts_with('!') { (&sub[1..], false) } else { (sub, true) };
Copy link
Contributor

@teor2345 teor2345 Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using ! for negation on the command-line is non-standard. It might also cause shell command parsing issues, because ! is a history search and insert metacharacter in some common shells.

The standard CLI negation prefix is no-, I suggest we use that instead.

The dev guide says to avoid no- for boolean flags, but I don't think that applies to more complex options:

- Avoid flags with the `no-` prefix. Instead, use the [`parse_bool`] function,
such as `-C embed-bitcode=no`.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I basically put ! as a placeholder. Let's wait with it for a little bit of time until we figure out what to do.

@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch from c72b434 to 2f2a134 Compare November 27, 2025 15:15
Ariel Ben-Yehuda added 3 commits November 27, 2025 15:33
This implements `-Z allow-partial-mitigations` as an unstable option,
currently with support for control-flow-guard and stack-protector.

As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo`
rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy
way to have an allow/deny pair of flags where the latter flag wins.

To allow for stabilization, this is only enabled starting from the next edition. Maybe a
better policy is possible (bikeshed).
@arielb1 arielb1 force-pushed the enforce-partial-mitigations branch from 2f2a134 to 99913dd Compare November 27, 2025 16:09
@rustbot
Copy link
Collaborator

rustbot commented Nov 27, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants