Files
rust/tests/ui/parser
Matthias Krüger 7ab385e2e1 Rollup merge of #139854 - fmease:modern-diag-for-lt-in-ty, r=davidtwco
Improve parse errors for stray lifetimes in type position

While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`).

Therefore let's *lie* in modern editions (just like in PR https://github.com/rust-lang/rust/pull/131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR https://github.com/rust-lang/rust/pull/69760).

I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice.

Fixes #133413.

[^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.
2025-04-17 00:16:22 +02:00
..
2024-12-08 15:32:04 +08:00
2024-12-10 11:34:13 +08:00
2023-01-11 09:32:08 +00:00
2025-01-07 16:04:14 +01:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2025-01-07 16:04:14 +01:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-11-29 06:10:15 +11:00
2023-05-05 21:44:48 +02:00
2023-05-05 21:44:48 +02:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-26 10:52:57 +08:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-11-16 20:03:31 +00:00
2023-01-11 09:32:08 +00:00
2023-05-05 11:17:14 -04:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-10-11 11:30:08 -04:00
2024-11-29 06:10:15 +11:00
2023-01-11 09:32:08 +00:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2024-04-21 15:43:43 -03:00
2025-01-07 16:04:14 +01:00
2025-01-07 16:04:14 +01:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2025-01-07 16:04:14 +01:00
2023-01-11 09:32:08 +00:00
2023-10-04 01:35:07 +00:00
2023-10-04 01:35:07 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2025-02-28 08:36:12 +11:00
2025-02-28 08:36:12 +11:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-11-24 19:42:33 +01:00
2024-11-24 19:42:33 +01:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-09-21 20:07:52 +03:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-19 02:25:55 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00