Fix and improve diagnostics for lint rust_2021_prefixes_incompatible_syntax

[fmease]

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]

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

[fmease]

Unfortunately, the "future incompatible" reason is tied to the lint.¹

I would've loved to keep EditionError for unknown prefixes and only use EditionSemanticsChange for known ones (c and cr).

I could introduce a new reason like EditionErrorOrSemanticsChange but I still wouldn't be able to dynamically change anything, so the diagnostic message would end up being super vague and there's not much value in that.

View changes since the review

Footnotes

1. While you're able to pass an ad-hoc const { &Lint { info: $0, ..*RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX } } to e.g., buffer_lint, any customization will end up getting dropped because lints are identified by pointer address, not contents. ↩

[mejrs]

Unfortunately, the "future incompatible" reason is tied to the lint.

Another option is to remove it here and add it to the diagnostic struct, like this:

rust/compiler/rustc_attr_parsing/src/diagnostics.rs

Lines 1318 to 1321 in 3ffb26f

	#[warning(
	"this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!"
	)]
	pub previously_accepted: bool,

[mejrs]

Another option is to create a new lint, so we have a split for "this is reserved" and "this has another meaning now"

[fmease]

I definitely don't want to create a new lint / split the lint since that'd be overkill for such a minute change: I don't want to involve T-lang and add all the boilerplate. Moreover, it's but a migration lint for an edition that isn't even the most recent one. Lastly, "semantics change" is technically correct anyway even for things that would unconditionally error in Rust >=2021, it's just more vague.

I'll look into the diagnostic struct thing, thanks! :) am on mobile rn

[fmease]

Revisiting this

Unfortunately, the "future incompatible" reason is tied to the lint.

Another option is to remove it here […]

We can't just remove the @future_incompatible thingy since it carries semantic meaning. The (mandatory) reason stores the edition (here: Rust 2021) in the case of edition lints which is then used to put the relevant lint into the corresponding lint group (rust_20XX_compatibility).

Trying to manually put it into that lint group after it's been registered would feel very much like working against the grain if it's even possible.

[rustbot]

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.