-
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
universal-regions table not populated with late bound lifetimes from parent functions #52113
Comments
Indeed, this is a bit tricky. I'm not actually sure how we should handle this case where we have a late-bound lifetime ( I suppose we probably have to create a kind of "special treatment" for these things, where we make a dedicated region-vid for each of the (named) late-bound lifetimes in the parent and we include that as part of the |
So, to try and elaborate a bit more on what I was saying in my previous comment: In the case of a late-bound region from a parent function, it will be not be part of the closure's generics. It may show up in the types of upvars or something like that. So for example if you had: fn foo<'a>(x: &'a u32, mut y: Vec<&'a u32>) {
let closure = move || y.push(x);
...
} then the closure would have two upvars ( The interesting thing though is that the closure doesn't know that. The way that we check closures is to replace all the free regions that appear in their signatures with fresh names. So, from the closure's point of view, it has two upvars: Our caller meanwhile knows that So now the problem is: imagine that the user wrote What I think we want to do is this:
So to work through an example, if you had: fn foo<'a, 'b>(x: &'a u32) {
let closure = move || {
let v: &'b u32 = x; // should be an error...
};
...
} then we will wind up (in the closure body) with an upvar of |
Should be fixed now |
Fix wrong issue number in the test name I made a mistake in previous PR rust-lang#52620, second issue number was wrong, changing from rust-lang#52133 to rust-lang#52113 r? @kennytm
Fix wrong issue number in the test name I made a mistake in previous PR rust-lang#52620, second issue number was wrong, changing from rust-lang#52133 to rust-lang#52113 r? @kennytm
Fix wrong issue number in the test name I made a mistake in previous PR rust-lang#52620, second issue number was wrong, changing from rust-lang#52133 to rust-lang#52113 r? @kennytm
Fix wrong issue number in the test name I made a mistake in previous PR rust-lang#52620, second issue number was wrong, changing from rust-lang#52133 to rust-lang#52113 r? @kennytm
This example:
causes an ICE:
This is split off from #51351 and I think retains the spirit of the original example better.
The text was updated successfully, but these errors were encountered: