-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position #145463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@bors try |
This comment has been minimized.
This comment has been minimized.
[WIP] Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
This comment was marked as outdated.
This comment was marked as outdated.
Nominating for T-lang FCP. Please refer to PR description for request. @rustbot label: +I-lang-nominated |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
@rustbot ready |
Thanks everybody! @bors r+ rollup |
Rollup of 6 pull requests Successful merges: - #145463 (Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position) - #145929 (fix APITIT being treated as a normal generic parameter in suggestions) - #146001 (Update getopts to remove unicode-width dependency) - #146365 (triagebot: warn about #[rustc_intrinsic_const_stable_indirect]) - #146366 (add approx_delta to all gamma tests) - #146373 (fix comments about trait solver cycle heads) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #145463 - jieyouxu:error-suffix, r=fmease Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position Tracking issue: #60210 Closes #60210 ## Summary Bump the ["suffixes on a tuple index are invalid" non-lint pseudo future-incompatibility warning (#60210)][issue-60210][^non-lint] 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 #59418. - We tried to hard reject all invalid suffixes in #59421, but unfortunately it turns out there were proc macros accidentally relying on it: #60138. - We temporarily accepted `{i,u}{32,size}` in #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 ```rs 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 ```rs 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 ```rs 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: ```rs 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): ```rs let i = 0; quote! { foo.$i } ``` where the user needs to actually write ```rs 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 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 - [x] Run crater to check if anyone is still relying on this being not a hard error. Determine degree of ecosystem breakage. - [x] If degree of breakage seems acceptable, draft nomination report for T-lang for FCP. - [x] Determine hard error on Edition 2024+, or on all editions. ## Accompanying Reference update - rust-lang/reference#1966 [^non-lint]: 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 #60186 (comment). [issue-60210]: #60210
Bors, this has already been merged. @bors r- |
Tracking issue: #60210
Closes #60210
Summary
Bump the "suffixes on a tuple index are invalid" non-lint pseudo future-incompatibility warning (#60210)1 to a hard error across all editions, rejecting the remaining carve outs from accidentally accepted invalid suffixes since Rust 1.27.
{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.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 indexingPosition 2: Invalid
{i,u}{32,size}
suffixes in tuple struct indexingPosition 3: Invalid
{i,u}{32,size}
suffixes in numeric struct field namesPosition 4: Invalid
{i,u}{32,size}
suffixes instd::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:The above forms in proc macros
For instance, constructions like (see tracking issue #60210):
where the user needs to actually write
Crater results
Conducted a crater run (#145463 (comment)).
usize
" in derive macro. Has a ton of other build warnings, last updated 6 years ago.quote
'sToTokens
on ausize
index (i.e. on tuple structTup(())
), the generated suffix becomes.0usize
(cf. Position 2).Review remarks
Tasks
Accompanying Reference update
Footnotes
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. ↩