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: "explicit lifetime required" error fails to highlight usage that introduces constraint #51175

Closed
7 tasks
pnkfelix opened this issue May 29, 2018 · 2 comments
Closed
7 tasks
Labels
A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal
Milestone

Comments

@pnkfelix
Copy link
Member

pnkfelix commented May 29, 2018

There are a collection of tests where NLL is failing to highlight the expression relevant to debugging some lifetime error.

Here is the list of tests that pnkfelix believes falls into that category:

Here's an explanation of the kind of (mis)behavior being described here:

In the following test ( ex1-return-one-existing-name-if-else-3.rs ):

fn foo<'a>((x, y): (&'a i32, &i32)) -> &'a i32 {
    if x > y { x } else { y } //~ ERROR explicit lifetime
}

here is the error output from AST borrowck ( ex1-return-one-existing-name-if-else-3.stderr )

error[E0621]: explicit lifetime required in parameter type
  --> $DIR/ex1-return-one-existing-name-if-else-3.rs:12:27
   |
LL | fn foo<'a>((x, y): (&'a i32, &i32)) -> &'a i32 {
   |            ------ consider changing type to `(&'a i32, &'a i32)`
LL |     if x > y { x } else { y } //~ ERROR explicit lifetime
   |                           ^ lifetime `'a` required

while this is the error output from NLL: ( ex1-return-one-existing-name-if-else-3.nll.stderr ):

warning: not reporting region error due to nll
  --> $DIR/ex1-return-one-existing-name-if-else-3.rs:12:27
   |
LL |     if x > y { x } else { y } //~ ERROR explicit lifetime
   |                           ^

error[E0621]: explicit lifetime required in parameter type
  --> $DIR/ex1-return-one-existing-name-if-else-3.rs:11:13
   |
LL | fn foo<'a>((x, y): (&'a i32, &i32)) -> &'a i32 {
   |            -^----
   |            ||
   |            |lifetime `'a` required
   |            consider changing type to `(&'a i32, &'a i32)`

error: aborting due to previous error

Note in particular that the error is failing to report the expression (namely the occurrence of y in an expression context that is expecting a &'a i32) that is injecting the lifetime constraint that lead it to suggest the change to the parameter type.

(It seems likely that the span of interest is probably immediately available, given that the warning we emit about not reporting a region error does highlight the span in which we are interested.)

@pnkfelix pnkfelix added NLL-diagnostics Working towards the "diagnostic parity" goal A-NLL Area: Non-lexical lifetimes (NLL) WG-compiler-nll labels May 29, 2018
@nikomatsakis
Copy link
Contributor

Marking as deferred as this is sort of a subissue of #51188

@nikomatsakis
Copy link
Contributor

This still seems to be a problem. Since we are closing #51188, I'm pulling this out into its own issue and putting it on the RC milestone, though it may be that it's more of a "final release" level issue still.

@davidtwco davidtwco assigned davidtwco and unassigned davidtwco Aug 6, 2018
bors added a commit that referenced this issue Aug 18, 2018
[NLL] Returns are interesting for free regions

Based on #53088 - creating now to get feedback.

Closes #51175

* Make assigning to the return type interesting.
* Use "returning this value" instead of "return" in error messages.
* Prefer one of the explanations that we have a name for to a generic interesting cause in some cases.
* Treat causes that involve the destination of a call like assignments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal
Projects
None yet
Development

No branches or pull requests

3 participants