Skip to content
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

[NLL] "'static requirement introduced here" note missing #97256

Open
jackh726 opened this issue May 21, 2022 · 1 comment
Open

[NLL] "'static requirement introduced here" note missing #97256

jackh726 opened this issue May 21, 2022 · 1 comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jackh726
Copy link
Member

jackh726 commented May 21, 2022

In the various revisions of src/test/ui/associated-types/cache/project-fn-ret-invariant.rs, we go from

error[E0759]: `x` has lifetime `'a` but it needs to satisfy a `'static` lifetime requirement
  --> $DIR/project-fn-ret-invariant.rs:55:9
   |
LL | fn baz<'a, 'b>(x: Type<'a>) -> Type<'static> {
   |                   -------- this data with lifetime `'a`...
...
LL |     bar(foo, x)
   |         ^^^  - ...is used and required to live as long as `'static` here
   |
note: `'static` lifetime requirement introduced by the return type
  --> $DIR/project-fn-ret-invariant.rs:51:37
   |
LL | fn baz<'a, 'b>(x: Type<'a>) -> Type<'static> {
   |                                     ^^^^^^^ `'static` requirement introduced here
...
LL |     bar(foo, x)
   |     ----------- because of this returned expression

to

error: lifetime may not live long enough
  --> $DIR/project-fn-ret-invariant-nll.rs:56:5
   |
LL | fn baz<'a, 'b>(x: Type<'a>) -> Type<'static> {
   |        -- lifetime `'a` defined here
...
LL |     bar(foo, x)
   |     ^^^^^^^^^^^ returning this value requires that `'a` must outlive `'static`
   |
   = note: requirement occurs because of the type `Type<'_>`, which makes the generic argument `'_` invariant
   = note: the struct `Type<'a>` is invariant over the parameter `'a`
   = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance

We lose the note, particularly the bit pointing to the return type (it's sort of in the note, but not exactly)

@jackh726 jackh726 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. A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal labels May 21, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue May 22, 2022
Move remaining tests with NLL differences to revisions

Based on rust-lang#97206

I've already filed issues for any important differences that I've spotted: rust-lang#97252 rust-lang#97253 rust-lang#97256 rust-lang#97267

There is a lot here, but each commit is self-contained as a separate directory. I can split into separate PRs as wanted or needed.
@compiler-errors
Copy link
Member

This regression is related to #97267 (kinda, not really, but bear with me) -- all we have is the two regions' spans and a ConstraintCategory that tells us to print "returning this value" before "requires that [...]".

We could add more rich information into ConstraintCategory::Return, perhaps? Otherwise we really just don't have enough info funnelled down to where we're actually emitting errors to do much more than just print that it's a return value causing this outlives constraint.

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-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants