unlock unlimited code runs for $79, limited time →
NOSSLETTER.techLIVE
back to OSSpedia
backwards-compatibilitycompiler-internals

make -Ctarget-feature warnings more explicitly FCWs

Project: rust-lang/rust | Language: Rust | Concepts: backwards-compatibility, compiler-internals | Difficulty: mid
Link: https://github.com/rust-lang/rust/pull/162237

The problem

Warnings about unknown or unstable -Ctarget-feature options were not clearly marked as future-compatibility warnings (FCWs). This made it unclear to users that these warnings would become hard errors in the future, and did not direct them to the relevant tracking issue.

Why it's non-trivial

A naive fix might just change the warning message text, but to properly communicate the deprecation and future plans, the warnings should:

  • Explicitly state that this is a future-compat warning and will become a hard error.
  • Point users to a specific tracking issue for more information.
  • Update all relevant diagnostics and test outputs consistently, including for both unknown and unstable features.

The approach

The PR updates diagnostic definitions and all affected test outputs. Key code changes:

1. Add explicit future-compat notes and issue links to diagnostics:

+#[note(
+    "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!"
+)]
+#[note("for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>")]
pub(crate) struct UnknownCTargetFeature<'a> {
    pub feature: &'a str,
    #[subdiagnostic]
    pub possible_feature: Option<PossibleFeature<'a>>,
}

This change adds two new notes to the UnknownCTargetFeature diagnostic: one explaining the future-compat status, and one linking to the tracking issue. This makes the warning's future implications explicit.

2. Apply the same pattern to other related diagnostics:

#[derive(Diagnostic)]
#[diag("unstable feature specified for `-Ctarget-feature`: `{$feature}`")]
#[note("{$note}; its behavior can change in the future")]
+#[note(
+    "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!"
+)]
+#[note("for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>")]
pub(crate) struct UnstableCTargetFeature<'a> {
    pub feature: &'a str,
    pub note: &'a str,
}

The same future-compat note and issue link are added to the diagnostic for unstable features.

3. Update all references to the old tracking issue to the new one:

-   = note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
+   = note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>

All diagnostics and test outputs that referenced the old issue are updated to point to the new, dedicated tracking issue.

4. Update test output files to match the new diagnostics:

Example:

 warning: unstable feature specified for `-Ctarget-feature`: `hvx-length128b`
    |
    = note: this feature is not stably supported; its behavior can change in the future
+   = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+   = note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>

Test .stderr files are updated to expect the new notes, ensuring test coverage for the new diagnostics.

From the review thread

No notable review discussion on this PR.

Takeaways

  • When deprecating or changing the behavior of a compiler feature, always communicate the transition clearly to users via diagnostics, including explicit future-compatibility warnings.
  • Link to a dedicated tracking issue in diagnostics so users can find more context and follow the transition plan.
  • Update all related diagnostics and test outputs to ensure consistency and avoid confusion during the deprecation process.
make -Ctarget-feature warnings more explicitly FCWs — nossletter.tech