https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=cargo_update 2025-09-16T18:38:08+00:00 2025-09-16T18:38:08+00:00 Esteban Küber esteban@osdyne.com 2025-09-16T18:38:08+00:00 urn:sha1:e9270e3cba3da56d4d83ed74f648e53b041cb263 When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported". ``` error: unexpected `...` --> $DIR/no-closure.rs:6:35 | LL | const F: extern "C" fn(...) = |_: ...| {}; | ^^^ | = note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list ``` 2025-09-15T09:53:29+00:00 Esteban Küber esteban@osdyne.com 2025-09-15T09:53:29+00:00 urn:sha1:9405e76431374e25077b374ed0cd9c920a1c0f4f ``` error: unexpected `...` --> $DIR/varargs-in-closure-isnt-supported.rs:5:20 | LL | let mut lol = |...| (); | ^^^ not a valid pattern | = note: C-variadic type `...` is not allowed here ``` 2025-09-11T04:06:32+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-11T04:06:32+00:00 urn:sha1:d037d1097fe62a9ec5dfcb211cbe334f2d635428 Less greedily parse `[const]` bounds > [!IMPORTANT] > If you're coming here from any beta backport nomination thread on Zulip, only the last commit is truly relevant (the first commit doesn't need to be backported, it only contains test modifications)! Don't consider `[` to start a bound, only consider `[const]` in its entirety to do so. This drastically reduces (but doesn't eliminate!) the chance of *real* breakages. Like `const`, `~const` and `async` before, `[const]` unavoidably brings along theoretical breakages, see preexisting tests: `macro-const-trait-bound-theoretical-regression.rs` and `macro-async-trait-bound-theoretical-regression.rs`. Side note: It's unfortunate that we have to do this but apart from the known fact that MBE hurts forward compatibility, the `[const]` syntax is simply a bit scuffed (also CC'ing https://github.com/rust-lang/rust/issues/146122, section (3)). Fixes [after beta backport] rust-lang/rust#146417. * 1st commit: Restore the original test intentions of several preexisting related tests that were unfortunately lost over time * I've added a bunch of SCREAMING comments to make it less likely to be lost again * CC PR rust-lang/rust#119099 which added most of these tests * CC [#144409 (comment)](https://github.com/rust-lang/rust/pull/144409#discussion_r2337587513) for further context (NB: It's not the only PR that negatively affected the test intention) * 2nd commit: Actually address the regression r? `@oli-obk` or anyone 2025-09-10T21:24:31+00:00 León Orell Valerian Liehr me@fmease.dev 2025-09-10T19:41:00+00:00 urn:sha1:f5dad62d4cdf139fb1c6cf2fa24ac525167501cc 2025-09-10T21:24:31+00:00 León Orell Valerian Liehr me@fmease.dev 2025-09-10T19:40:24+00:00 urn:sha1:1558e65c9eec9ee0309e1920266e0a4325b63784 2025-09-10T18:29:09+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-10T18:29:09+00:00 urn:sha1:86d39a06734cae9492d83498aac9bbdf3aa20508 Strip frontmatter in fewer places * Stop stripping frontmatter in `proc_macro::Literal::from_str` (RUST-146132) * Stop stripping frontmatter in expr-ctxt (but not item-ctxt!) `include`s (RUST-145945) * Stop stripping shebang (!) in `proc_macro::Literal::from_str` * Not a breaking change because it did compare spans already to ensure there wasn't extra whitespace or comments (`Literal::from_str("#!\n0")` already yields `Err(_)` thankfully!) * Stop stripping frontmatter+shebang inside some rustdoc code where it doesn't make any observable difference (see self review comments) * (Stop stripping frontmatter+shebang inside internal test code) Fixes https://github.com/rust-lang/rust/issues/145945. Fixes https://github.com/rust-lang/rust/issues/146132. r? fee1-dead 2025-09-09T17:49:40+00:00 León Orell Valerian Liehr me@fmease.dev 2025-09-08T17:25:22+00:00 urn:sha1:7a66925a8138df105f77d646f9206024baf7ea4b 2025-09-09T15:32:20+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-09T15:32:20+00:00 urn:sha1:12e548704e5c21c6f90a73937b3a7279119542c0 Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position Tracking issue: rust-lang/rust#60210 Closes rust-lang/rust#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 https://github.com/rust-lang/rust/issues/59418. - We tried to hard reject all invalid suffixes in https://github.com/rust-lang/rust/pull/59421, but unfortunately it turns out there were proc macros accidentally relying on it: https://github.com/rust-lang/rust/issues/60138. - We temporarily accepted `{i,u}{32,size}` in https://github.com/rust-lang/rust/pull/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 rust-lang/rust#60186 as an ecosystem impact mitigation measure (cf. rust-lang/rust#60138). Specifically, the following cases (particularly the construction of these forms in proc macros like reported in rust-lang/rust#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 rust-lang/rust#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 (https://github.com/rust-lang/rust/pull/145463#issuecomment-3194920383). - 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 https://github.com/AmlingPalantir/r4/issues/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 - https://github.com/rust-lang/reference/pull/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 https://github.com/rust-lang/rust/pull/60186#issuecomment-485581694. [issue-60210]: https://github.com/rust-lang/rust/issues/60210 2025-09-06T16:01:31+00:00 Moritz Hedtke Moritz.Hedtke@t-online.de 2025-09-06T16:01:31+00:00 urn:sha1:7fada167f9a3cfcfa35fbfc33a17b926f8ef3352 2025-09-02T15:08:57+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-09-02T15:08:57+00:00 urn:sha1:8408bca60502a2364b6104192089d27b2b6223fd Make `Parser::parse_for_head` public for rustfmt usage Similar to https://github.com/rust-lang/rust/pull/138511, I want to add [dioxus rsx](https://dioxuslabs.com/learn/0.6/reference/rsx) formatting to [my rustfmt fork](https://github.com/tucant/rustfmt) and it would be much easier if that method would be public. Thanks.