-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
"lifetime of borrowed pointer outlives lifetime of captured variable" error message very unclear #42574
Comments
Workaround (why would this work, but not the case above?): fn doit(data: &'static mut ()) {
|| {
let d = data;
doit(d);
};
} |
cc @nikomatsakis -- you've been doing some work on collecting these issues recently |
Hmm. This error seems to arise due to a couple of interacting things. In particular, the closure is a temporary value, and as the final expression in the function its lifetime winds up being too big in some cases (#21114), and that is (in part) what is causing this error -- or at least I think. In any case, I'll add it to the tracking issue and try to take a look at it later on! Thanks @Mark-Simulacrum for calling it out. |
Well, actually, I'll keep this open. |
Under the NLL migration mode, we get the existing (bad) error messaging. But under
|
My personal take is that the error message under I have tagged this as NLL-fixed-by-NLL, but it is worth pointing out that this is not fixed by the NLL migration mode. Do we need a separate tag for issues that require migrating from migration to |
Nominating for discussion at NLL meeting, just in terms of determining how this should be tagged to ensure that we keep it open until Also, it needs tests that encode the current semantics under all three revisions: |
triage: hmm clearly the WG-nll meetings need to do a better job of looking at the nominated issues. My bad. |
well, since I know that we are going to make a work queue from the things tagged as NLL-deferred, I'm going to add that tag to this issue. (But I'll also leave the I-nominated on it, since the question and tasks I posed above remain unresolved.) |
we discussed this at the NLL meeting. the rough consensus was that the NLL-fixed-by-NLL tag applies here, even though you need the full |
Re-triaging for #56754. NLL-fixed-by-NLL, so leaving open. Assigning to self for the main remaining task of adding the tests. But also tagging as P-low since I don't think that is a high priority task. |
reading this comment more carefully, now I too am wondering why we accept the above but not the original example. Stranger still, (depending on your POV), we still reject variants like this: #![feature(nll)]
fn doit(data: &'static mut ()) {
|| {
let d: &mut _ = data;
doit(d)
};
} What type are we inferring for |
…crichton Regression test for issue 42574. Cc rust-lang#42574. I'm not going to say this *closes* that issue yet, for two reasons: 1. I am still confused about some aspects of the behavior we are observing that bug 2. The "fix" to the diagnostic relies on full NLL (`#![feature(nll)]`); migration mode still has a subpar diagnostic.
…crichton Regression test for issue 42574. Cc rust-lang#42574. I'm not going to say this *closes* that issue yet, for two reasons: 1. I am still confused about some aspects of the behavior we are observing that bug 2. The "fix" to the diagnostic relies on full NLL (`#![feature(nll)]`); migration mode still has a subpar diagnostic.
A case that might change its behavior once this is fixed:
where it compile-passes if the |
@estebank I don't think #49616 is same as whats occuring here; I posted argument as to why over here on #21114. |
Triage: this produces an error message that seems fairly clear to me. Going to remove E-needs-test since #62520 added a test for this. @pnkfelix you mentioned in #62520 that you're "confused about some aspects of the behavior we are observing that bug" - is that captured here? Now that nll is fully a thing, can this be closed? |
What's the status of this issue? Can it be closed? |
@Aaron1011 I think this can be closed once we enable NLL by default, although I'm sure there are some tweaks we could make to the output to make it clearer:
|
Closing this as per the prior comments, we've been using the NLL borrow checker for a while now. |
For this code:
(works fine if you drop the
mut
, still happens with amove
closure).The compiler (stable and nightly) spits out this error:
for the lifetime as defined on
the actual lifetime is invisible. There is also no lifetime defined in the entire program, so it's not clear which lifetime the note is talking about.data
itself must live as long as the data behind the reference? Why?According to the rustc source code, this error is related to an implicit reborrow done by the closure. The error mentions nothing of that sort.
The text was updated successfully, but these errors were encountered: