Skip to content

Confusing diagnostic for stray lifetime in type #133413

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

Closed
Dylan-DPC opened this issue Nov 24, 2024 · 0 comments · Fixed by #139854
Closed

Confusing diagnostic for stray lifetime in type #133413

Dylan-DPC opened this issue Nov 24, 2024 · 0 comments · Fixed by #139854
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Dylan-DPC
Copy link
Member

Dylan-DPC commented Nov 24, 2024

Code

struct Bar;
pub struct Foo<'a>('a, Bar);

Current output

error: lifetime in trait object type must be followed by `+`
 --> src/lib.rs:2:20
  |
2 | pub struct Foo<'a>('a, Bar);
  |                    ^^

error[E0224]: at least one trait is required for an object type
 --> src/lib.rs:2:20
  |
2 | pub struct Foo<'a>('a, Bar);
  |                    ^^

Rationale and extra context

Playground link

Rust Version

Tested on playground so latest stable and nightly at the time of writing (1.82.0 stable)

@Dylan-DPC Dylan-DPC added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 24, 2024
@jieyouxu jieyouxu added D-confusing Diagnostics: Confusing error or lint that should be reworked. A-parser Area: The parsing of Rust source code to an AST labels Nov 24, 2024
@fmease fmease self-assigned this Nov 24, 2024
@fmease fmease changed the title Confusing diagnostic for stray lifetime in tuple struct Confusing diagnostic for stray lifetime in type Dec 7, 2024
@bors bors closed this as completed in 7ab385e Apr 17, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 17, 2025
Rollup merge of rust-lang#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 rust-lang#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 rust-lang#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 rust-lang#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants