-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
"expected &&str, found &&str" and missing context #57189
Comments
CC #18759 |
I found simpler one of these in the wild on the subreddit ask anything thread (I have simplified it here). The new user of Rust is trying to set up Gtk signal handlers. What happens here is that the closure tries to use
produces this error on 1.44 nightly
Maybe the the variable that has the longest lifetime should be pointed out by the error. |
It looks like this was recently fixed on stable. The error for the first example is now:
and for the second is
Fixing the errors and following more compiler errors appropriately fixes the problem. The only other problem I see is that it does not point out which line extends the lifetime, but I don't think it would be fixable in general. The error is much cleaner now. |
Edit: there is a simpler example I found below in the comments
I was trying to solve a lifetime issue another Rustacean had on the Reddit question thread and found this:
which triggers this gem (on
rustc 1.44.0-nightly (6dee5f112 2020-04-06)
):besides the title, there are other problems with the error reporting that happens with and without that
clone
:Just to make sure I am interpreting the problem as a whole right, is the lifetime of the
&str
passed tocount_words_parallel
getting elided along until it gets into the new threads via&chunk
? The lifetimes of the new threads are'static
which means that lifetime all the way back at the&str
must also be'static
or alternatively something has to happen along the way to split up lifetimes (which I was trying to do above viaclone
ing).The important point is that I had to work through all the lifetimes myself by prompting the compiler through other errors (in which it will give more info) to figure out what was what. Hindsight of course is 20/20 and now I can see the flow of this particular error message, this is what I think it is trying to tell me:
note: first, the lifetime cannot outlive the anonymous lifetime
"the lifetime" refers to the hashmap at the end of the lifetime elision chain mentioned at the end of the error.but, the lifetime must be valid for the static lifetime
I actually don't know what the first "lifetime" is but the "static lifetime" must be the thread spawning closure which is never pointed to (via the really helpful ascii lines and arrows).so that the type std::collections::HashMap<&str, usize> will meet its required lifetime bounds
"required" as in required by the lifetime of the thread spawning closure that was indirectly mentioned above this part of the error. "bounds" as in'static
The biggest problem I have always had with Rustc's error system when I get stuck is that a key piece of information is being withheld from me, and I believe it would help at this point to be more verbose and have redundancy to the wording. Perhaps have an error format that, for each lifetime involved, describes the where and what of the relevant variables and their lifetimes (saying stuff like "variable x has lifetime # 3, beginning and ending here"), and only after that describes what and how lifetimes collide (saying stuff like "this variable (having lifetime # 3) outlives this other variable (having lifetime # 2) via scoping or closures or whatnot at this place").
The text was updated successfully, but these errors were encountered: