Fix and improve diagnostics for lint rust_2021_prefixes_incompatible_syntax - #161792
Conversation
|
r? @adwinwhite rustbot has assigned @adwinwhite. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
4bb6b90 to
cfc1f5f
Compare
cfc1f5f to
1df00ae
Compare
|
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. |
| 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, | ||
| ) | ||
| } |
There was a problem hiding this comment.
Is this manual impl really necessary? You can use #[suggestion_verbose(..)] if it's just about the verbosity.
There was a problem hiding this comment.
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 | |||
There was a problem hiding this comment.
Can we change this lint to say what exactly the prefix would be?
| warning: parsed as a prefix in Rust 2021 and onward | |
| warning: `z` is parsed as a prefix in Rust 2021 and onward |
| span, | ||
| ast::CRATE_NODE_ID, | ||
| crate::diagnostics::ReservedPrefixLint { | ||
| kind: "C string literal", |
There was a problem hiding this comment.
This could also be a "raw C string literal"
1df00ae to
3fca755
Compare
|
Applied all 3 suggestions. |
…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>
…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>
…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)
…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)
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>
On main, when encountering token sequences in Rust <2021 that would get interpreted as...
cis unknown" / "prefixcris unknown" despite them obviously being known'r#a, we suggest splitting them after the hash (so'r#anda) which obviously doesn't fix the issue; they need to be split before the hash (so'rand#a)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)