Skip to content

Confusing diagnostic for stray lifetime in type #133413

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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 lexing & 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 lexing & 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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The lexing & 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