Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position

[jieyouxu]

Tracking issue: #60210
Closes #60210

Summary

Bump the "suffixes on a tuple index are invalid" non-lint pseudo future-incompatibility warning (#60210)¹ to a hard error across all editions, rejecting the remaining carve outs from accidentally accepted invalid suffixes since Rust 1.27.

• We accidentally accepted invalid suffixes in tuple indexing positions in Rust 1.27. Originally reported at Syntax: ignoring tuple index with a suffix (a.1lolololol) #59418.
• We tried to hard reject all invalid suffixes in Reject integer suffix when tuple indexing #59421, but unfortunately it turns out there were proc macros accidentally relying on it: suffixes on a tuple index are invalid  #60138.
• We temporarily accepted {i,u}{32,size} in Temporarily accept [i|u][32|size] suffixes on a tuple index and warn #60186 (the "carve outs") to mitigate immediate ecosystem impact, but it came with an FCW warning indicating that we wanted to reject it after a few Rust releases.
• Now (1.89.0) is a few Rust releases later (1.35.0), thus I'm proposing to also reject the carve outs.
  • std::mem::offset_of! stabilized in Rust 1.77.0 happens to use the same "don't expect suffix" code path which has the carve outs, so it also accepted the carve out suffixes. I'm proposing to reject this case as well.

What specifically breaks?

Code that still relied on invalid {i,u}{32,size} suffixes being temporarily accepted by #60186 as an ecosystem impact mitigation measure (cf. #60138). Specifically, the following cases (particularly the construction of these forms in proc macros like reported in #60138):

Position 1: Invalid {i,u}{32,size} suffixes in tuple indexing

fn main() {
    let _x = (42,).0invalid; // Already error, already rejected by #59421
    let _x = (42,).0i8;      // Already error, not one of the #60186 carve outs.
    let _x = (42,).0usize;   // warning: suffixes on a tuple index are invalid
}

Position 2: Invalid {i,u}{32,size} suffixes in tuple struct indexing

fn main() {
    struct X(i32);
    let _x = X(42);
	let _x = _x.0invalid; // Already error, already rejected by #59421
    let _x = _x.0i8;      // Already error, not one of the #60186 carve outs.
    let _x = _x.0usize;   // warning: suffixes on a tuple index are invalid
}

Position 3: Invalid {i,u}{32,size} suffixes in numeric struct field names

fn main() {
    struct X(i32, i32, i32);
    let _x = X(1, 2, 3);
    let _y = X { 0usize: 42, 1: 42, 2: 42 };    // warning: suffixes on a tuple index are invalid
	match _x {
        X { 0usize: 1, 1: 2, 2: 3 } => todo!(), // warning: suffixes on a tuple index are invalid
        _ => {}
    }
}

Position 4: Invalid {i,u}{32,size} suffixes in std::mem::offset_of!

While investigating the warning, unfortunately I noticed std::mem::offset_of! also happens to use the "expect no suffix" code path which had the carve outs. So this was accepted since Rust 1.77.0 with the same FCW:

fn main() {
    #[repr(C)]
    pub struct Struct<T>(u8, T);

    assert_eq!(std::mem::offset_of!(Struct<u32>, 0usize), 0);
    //~^ WARN suffixes on a tuple index are invalid
}

The above forms in proc macros

For instance, constructions like (see tracking issue #60210):

let i = 0;
quote! { foo.$i }

where the user needs to actually write

let i = syn::Index::from(0);
quote! { foo.$i }

Crater results

Conducted a crater run (#145463 (comment)).

• https://github.com/AmlingPalantir/r4/tree/256af3c72f094b298cd442097ef7c571d8001f29: genuine regression; "invalid suffix usize" in derive macro. Has a ton of other build warnings, last updated 6 years ago.
  • Exactly the kind of intended breakage. Minimized down to https://github.com/AmlingPalantir/r4/blob/256af3c72f094b298cd442097ef7c571d8001f29/validates_derive/src/lib.rs#L71-L75, where when interpolation uses quote's ToTokens on a usize index (i.e. on tuple struct Tup(())), the generated suffix becomes .0usize (cf. Position 2).
  • Notified crate author of breakage in FYI: Invalid suffix on tuple indexing AmlingPalantir/r4#1.
• Other failures are unrelated or spurious.

Review remarks

• Commits 1-3 expands the test coverage to better reflect the current situation before doing any functional changes.
• Commit 4 is an intentional breaking change. We bump the non-lint "suffixes on a tuple index are invalid" warning into a hard error. Thus, this will need a crater run and a T-lang FCP.

Tasks

• Run crater to check if anyone is still relying on this being not a hard error. Determine degree of ecosystem breakage.
• If degree of breakage seems acceptable, draft nomination report for T-lang for FCP.
• Determine hard error on Edition 2024+, or on all editions.

Footnotes

1. The FCW was implemented as a non-lint warning (meaning it has no associated lint name, and you can't #![deny(..)] it) because spans coming from proc macros could not be distinguished from regular field access. This warning was also intentionally impossible to silence. See https://github.com/rust-lang/rust/pull/60186#issuecomment-485581694. ↩

[jieyouxu]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: c6f1a85 (c6f1a85c8f06c93ddc6200caf413929a2e7e7dd6, parent: cd7cbe818e4a66d46fe2df993d1b8518eba8a5cd)

[jieyouxu]

@craterbot check

[craterbot]

👌 Experiment pr-145463 created and queued.
🤖 Automatically detected try build c6f1a85
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-145463 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-145463 is completed!
📊 7 regressed and 4 fixed (683072 total)
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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

[jieyouxu]

Nominating for T-lang FCP. Please refer to PR description for request.

@rustbot label: +I-lang-nominated

[fmease]

r=me after nits and if/once T-lang approves with a fFCP-merge.

[rustbot]

This PR was rebased onto a different master 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.

[jieyouxu]

Addressed nits in (range-diff)¹

Footnotes

1. So nice <3 ↩

[traviscross]

Let's do it. Thanks @jieyouxu for putting it forward and for the great write-up.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[ehuss]

Can we get a PR to the reference to update everything there?
I'm not sure all that needs to be updated, but there is possibly:

• The note
• The grammar. I think that includes TUPLE_INDEX? I'm not sure what else.

[jieyouxu]

Sure. I'll send one tmrw / Wednesday. Will need to double-check which bits of the grammar needs updating tho.