Skip to content

Fix and improve diagnostics for lint rust_2021_prefixes_incompatible_syntax - #161792

Merged
rust-bors[bot] merged 3 commits into
rust-lang:mainfrom
fmease:fix-reserved-prefixes-lint-diags
Aug 31, 2026
Merged

Fix and improve diagnostics for lint rust_2021_prefixes_incompatible_syntax#161792
rust-bors[bot] merged 3 commits into
rust-lang:mainfrom
fmease:fix-reserved-prefixes-lint-diags

Conversation

@fmease

@fmease fmease commented Aug 26, 2026

Copy link
Copy Markdown
Member

On main, when encountering token sequences in Rust <2021 that would get interpreted as...

  1. ...C string literals in Rust >=2021,
    1. we report "prefix c is unknown" / "prefix cr is unknown" despite them obviously being known
    2. we claim that they "[are] a hard error in Rust 2021"
  2. ...raw lifetimes in Rust >=2021 like 'r#a, we suggest splitting them after the hash (so 'r# and a) which obviously doesn't fix the issue; they need to be split before the hash (so 'r and #a)
  3. ...unknown (reserved) prefixes in Rust >=2021, we report "prefix […] is unknown" but to be pedantic the sequence is not a prefix in the current edition, it's just a normal identifier; to be correct & precise we should thus say that they will be parsed as a prefix (in Rust >=2021)

Lastly, unify / streamline all diagnostics pertaining to "reserved prefixes" (identifier/literal prefixes, hash prefixes (aka guarded string prefixes / multihashes))


Best reviewed commit by commit.

Note

Unblocks PR #161775.

(No LLM was or will be used by me during the entire creation process of this PR)

@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 Aug 26, 2026
@rustbot

rustbot commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

r? @adwinwhite

rustbot has assigned @adwinwhite.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 17 candidates

@rust-log-analyzer

This comment has been minimized.

Comment thread compiler/rustc_lint_defs/src/builtin.rs
@fmease
fmease force-pushed the fix-reserved-prefixes-lint-diags branch from 4bb6b90 to cfc1f5f Compare August 26, 2026 01:09
@fmease
fmease force-pushed the fix-reserved-prefixes-lint-diags branch from cfc1f5f to 1df00ae Compare August 27, 2026 14:36
@rustbot

rustbot commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

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.

@mejrs mejrs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

r? me

I agree with the general approach/direction here, just have some comments

View changes since this review

Comment thread compiler/rustc_parse/src/diagnostics.rs Outdated
Comment on lines +4633 to +4644
impl<'a> Diagnostic<'a, ()> for ReservedPrefixLint {
fn into_diag(self, dcx: DiagCtxtHandle<'a>, level: Level) -> Diag<'a, ()> {
let Self { kind, edition, sugg } = self;

#[derive(Diagnostic)]
#[diag("reserved token in Rust 2024")]
pub(crate) struct ReservedMultihashLint {
#[suggestion(
"insert whitespace here to avoid this being parsed as a forbidden token in Rust 2024",
code = " ",
applicability = "machine-applicable"
)]
pub suggestion: Span,
Diag::new(dcx, level, format!("parsed as a {kind} in Rust {edition} and onward"))
.with_span_suggestion_verbose(
sugg,
"consider inserting whitespace here to avoid this",
" ",
Applicability::MachineApplicable,
)
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is this manual impl really necessary? You can use #[suggestion_verbose(..)] if it's just about the verbosity.

@fmease fmease Aug 30, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Ah, it's a remnant from when I had an enum w/ payloads for the kind and impl'ed it manually to avoid duplicating the mostly shared suggestion; now I should indeed be able to use the derive.

@@ -1,69 +1,69 @@
warning: prefix `z` is unknown
warning: parsed as a prefix in Rust 2021 and onward

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can we change this lint to say what exactly the prefix would be?

Suggested change
warning: parsed as a prefix in Rust 2021 and onward
warning: `z` is parsed as a prefix in Rust 2021 and onward

Comment thread compiler/rustc_parse/src/lexer/mod.rs Outdated
span,
ast::CRATE_NODE_ID,
crate::diagnostics::ReservedPrefixLint {
kind: "C string literal",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This could also be a "raw C string literal"

@rustbot rustbot assigned mejrs and unassigned adwinwhite Aug 30, 2026
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 30, 2026
@fmease
fmease force-pushed the fix-reserved-prefixes-lint-diags branch from 1df00ae to 3fca755 Compare August 30, 2026 17:29
@fmease

fmease commented Aug 30, 2026

Copy link
Copy Markdown
Member Author

Applied all 3 suggestions.

@fmease fmease added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 30, 2026
@fmease
fmease requested a review from mejrs August 30, 2026 17:30

@mejrs mejrs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@rust-bors

rust-bors Bot commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 3fca755 has been approved by mejrs

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 30, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 30, 2026
…diags, r=mejrs

Fix and improve diagnostics for lint `rust_2021_prefixes_incompatible_syntax`

On main, when encountering token sequences in Rust <2021 that would get interpreted as...

1. ...C string literals in Rust >=2021,
   1. we report "*prefix `c` is unknown*" / "*prefix `cr` is unknown*" despite them obviously being known
   2. we claim that they "*[are] a hard error in Rust 2021*"
2. ...raw lifetimes in Rust >=2021 like `'r#a`, we suggest splitting them *after* the hash (so `'r#` and `a`) which obviously doesn't fix the issue; they need to be split *before* the hash (so `'r` and `#a`)
3. ...unknown (reserved) prefixes in Rust >=2021, we report "*prefix […] is unknown*" but to be pedantic the sequence is *not* a prefix in the current edition, it's just a normal identifier; to be correct & precise we should thus say that they *will* be parsed as a prefix (in Rust >=2021)

Lastly, unify / streamline all diagnostics pertaining to "reserved prefixes" (identifier/literal prefixes, hash prefixes (aka guarded string prefixes / multihashes))

---

Best reviewed commit by commit.

> [!NOTE]
> **Unblocks** PR rust-lang#161775.

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 30, 2026
…diags, r=mejrs

Fix and improve diagnostics for lint `rust_2021_prefixes_incompatible_syntax`

On main, when encountering token sequences in Rust <2021 that would get interpreted as...

1. ...C string literals in Rust >=2021,
   1. we report "*prefix `c` is unknown*" / "*prefix `cr` is unknown*" despite them obviously being known
   2. we claim that they "*[are] a hard error in Rust 2021*"
2. ...raw lifetimes in Rust >=2021 like `'r#a`, we suggest splitting them *after* the hash (so `'r#` and `a`) which obviously doesn't fix the issue; they need to be split *before* the hash (so `'r` and `#a`)
3. ...unknown (reserved) prefixes in Rust >=2021, we report "*prefix […] is unknown*" but to be pedantic the sequence is *not* a prefix in the current edition, it's just a normal identifier; to be correct & precise we should thus say that they *will* be parsed as a prefix (in Rust >=2021)

Lastly, unify / streamline all diagnostics pertaining to "reserved prefixes" (identifier/literal prefixes, hash prefixes (aka guarded string prefixes / multihashes))

---

Best reviewed commit by commit.

> [!NOTE]
> **Unblocks** PR rust-lang#161775.

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
rust-bors Bot pushed a commit that referenced this pull request Aug 30, 2026
…uwer

Rollup of 11 pull requests

Successful merges:

 - #160923 (Handle multiple action records in EH personality function)
 - #161788 (Check to ensure we're running against the correct LLVM version)
 - #158303 (Always escape grapheme extenders in `str::escape_debug`)
 - #161644 (bootstrap: Flatten and rename `compute_src_directory_via_git`)
 - #161702 (Use `drop_guard` in some places in {core,alloc,std})
 - #161713 (Add config for gram editor to .gitignore)
 - #161792 (Fix and improve diagnostics for lint `rust_2021_prefixes_incompatible_syntax`)
 - #161931 (Revert "Add rustc_test_entrypoint_marker")
 - #162015 (touch up "get attribute" docs.)
 - #162019 (remove a couple of redundant clones, thanks clippy)
 - #162023 (Remove redundant braces from `NonZero` doctests)
rust-bors Bot pushed a commit that referenced this pull request Aug 30, 2026
…uwer

Rollup of 11 pull requests

Successful merges:

 - #160923 (Handle multiple action records in EH personality function)
 - #161788 (Check to ensure we're running against the correct LLVM version)
 - #158303 (Always escape grapheme extenders in `str::escape_debug`)
 - #161644 (bootstrap: Flatten and rename `compute_src_directory_via_git`)
 - #161702 (Use `drop_guard` in some places in {core,alloc,std})
 - #161713 (Add config for gram editor to .gitignore)
 - #161792 (Fix and improve diagnostics for lint `rust_2021_prefixes_incompatible_syntax`)
 - #161931 (Revert "Add rustc_test_entrypoint_marker")
 - #162015 (touch up "get attribute" docs.)
 - #162019 (remove a couple of redundant clones, thanks clippy)
 - #162023 (Remove redundant braces from `NonZero` doctests)
@rust-bors
rust-bors Bot merged commit dd9c329 into rust-lang:main Aug 31, 2026
13 checks passed
@rustbot rustbot added this to the 1.100.0 milestone Aug 31, 2026
rust-bors Bot pushed a commit that referenced this pull request Aug 31, 2026
Rollup merge of #161792 - fmease:fix-reserved-prefixes-lint-diags, r=mejrs

Fix and improve diagnostics for lint `rust_2021_prefixes_incompatible_syntax`

On main, when encountering token sequences in Rust <2021 that would get interpreted as...

1. ...C string literals in Rust >=2021,
   1. we report "*prefix `c` is unknown*" / "*prefix `cr` is unknown*" despite them obviously being known
   2. we claim that they "*[are] a hard error in Rust 2021*"
2. ...raw lifetimes in Rust >=2021 like `'r#a`, we suggest splitting them *after* the hash (so `'r#` and `a`) which obviously doesn't fix the issue; they need to be split *before* the hash (so `'r` and `#a`)
3. ...unknown (reserved) prefixes in Rust >=2021, we report "*prefix […] is unknown*" but to be pedantic the sequence is *not* a prefix in the current edition, it's just a normal identifier; to be correct & precise we should thus say that they *will* be parsed as a prefix (in Rust >=2021)

Lastly, unify / streamline all diagnostics pertaining to "reserved prefixes" (identifier/literal prefixes, hash prefixes (aka guarded string prefixes / multihashes))

---

Best reviewed commit by commit.

> [!NOTE]
> **Unblocks** PR #161775.

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
@fmease
fmease deleted the fix-reserved-prefixes-lint-diags branch August 31, 2026 04:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

5 participants