Description
This is a general tracking issue for the work on improving lifetime errors (in particular the "cannot infer lifetime" error E0495, but also including other errors). This is a rather large project, since there are many different classes of errors, so part of the work is finding scenarios and making more targeted error messages for them.
In general, I am trying to track errors and brainstorm here. There is also an etherpad where I have done some note-taking.
Current road-map
The plan is to have three major kinds of errors, delivered in order of preference. The basic work here is done, but there remain gaps to be covered. If you're interested in helping out, check out the issues associated with the unchecked check boxes!
- "explicit lifetime required" (example)
- these are cases where the user has an explicit lifetime name, but they need to use it in more places
- Format self correctly #42700 -- we don't handle the case where the anonymous lifetime appears in
selfvery well
- properly handle anonymous regions appearing in return type- named-anon conflicts #42703 -- "this parameter and the return type are declared with different lifetimes..." (adding E0623 for return types - both parameters are anonymous #44124)
- "these two types are declared with different lifetimes..." (example)
- This is a sort of fallback. It covers all kinds of cases.
- "these two types are declared with different lifetimes..." not triggering within structs #44508 -- it doesn't work on lifetimes in structs
- In particular, the goal with the base message is just to describe what the problem is without suggesting a particular solution. We then want to consider various extensions where we can propose a fix:
- Suggest a new signature (region errors: suggest new signature #44506)
- Suggest adding a where clause when there are already two named lifetimes (suggest adding a where-clause #44507)
- We have to be careful in the above cases around methods appearing in an impl of a trait, since the user may not have freedom to change the signature. Here are some cases:
- Improve impl implements different signature from trait error message #42706 -- impl does not use the same signature as declared in the trait
- Cross-cutting concerns:
- Handle
SubSup-style errors and not just concrete failures (Improve case with one named, one anonymous lifetime parameter - SubSupConflict Errors #42701) - improve case with both anonymous lifetime parameters in functions and trait objects. #43276 -- double-check behavior in case with more binders
- Handle
- Higher-ranked closure error messages should avoid "anonymous lifetime bind's glue function should tail-call its target #2 defined on the body" Higher-ranked closure error messages should avoid "anonymous lifetime #2 defined on the body" #45983
- smarter blame assignment for lifetime inference errors smarter blame assignment for lifetime inference errors #45979
Examples in need of analysis
- "lifetime of borrowed pointer outlives lifetime of captured variable" error message very unclear #42574 -- weird interaction with closures and
&'staticarguments
Future plans
- Improve how lifetime inference selects which edges in the region inference graph are at fault. The code for finding the regions that conflict seems to work quite well -- but the code to select which edges to blame is hopeless. I think we need to look specifically for cases where the user "puts things in tension" (e.g.,
foo(a)puts the formal declarations offooin tension with the type ofa). I'll try to write up these thoughts in a bit more detail later.
Other issues
Here are various issues that I have subsumed into this one. These are a checklist because I want to go over them and extract any key examples into this issue and then close them. Feel free to do so (in the comments).
- Error message for inferred lifetime failure isn't great #40900
- confusing lifetime inference #33529
- Confusing lifetime inference error / error messages #30387
- ReSkolemized can leak into error messages #13998 -- this needs to be verified, maybe out of date
- Handle ADTs with implicit lifetime params resulting a lifetime mismatch in fn definition #40990