-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
dropck seems overconservative when dealing with matches at the end of a block #22252
Comments
This may be a dup of #21114 |
I think this might be a consequence of our rules for r-value temporaries, where the temporaries in the expression at the end of a block are assigned a lifetime longer than that of the But then again, that answer is not very satisfying without an example of what kind of unsoundness this is supposedly preventing. (I do not have an example ready on hand, but you've given me a place to start.) |
cc #22321 |
also, cc #12032 ;) |
The problem does not require a Simpler reproduction code: #![feature(unsafe_destructor)]
struct Foo;
struct FooRef<'a>(&'a Foo);
impl<'a> FooRef<'a> {
fn borrow(&self) {}
}
#[unsafe_destructor]
impl<'a> Drop for FooRef<'a> {
fn drop(&mut self) {}
}
fn main() {
let x = Foo;
FooRef(&x).borrow()
} The error: <anon>:17:13: 17:14 error: `x` does not live long enough
<anon>:17 FooRef(&x).borrow()
^
<anon>:15:11: 18:2 note: reference must be valid for the destruction scope surrounding block at 15:10...
<anon>:15 fn main() {
<anon>:16 let x = Foo;
<anon>:17 FooRef(&x).borrow()
<anon>:18 }
<anon>:16:16: 18:2 note: ...but borrowed value is only valid for the block suffix following statement 0 at 16:15
<anon>:16 let x = Foo;
<anon>:17 FooRef(&x).borrow()
<anon>:18 } |
Due to rust-lang/rust#22252, r-value temporaries outlive the lifetimes of variables bound with let statements in a function body. Because of this, device.rs fails to compile against newer rustc nightlies. This implements a simple workaround that binds the result of the match in `request_code` to a local variable before returning it. This allows it to have the same lifetime as `req` in one of the previous let bindings.
Due to rust-lang/rust#22252, r-value temporaries outlive the lifetimes of variables bound with let statements in a function body. Because of this, device.rs fails to compile against newer rustc nightlies. This implements a simple workaround that binds the result of the match in `request_code` to a local variable before returning it. This allows it to have the same lifetime as `req` in one of the previous let bindings.
Due to rust-lang/rust#22252, r-value temporaries outlive the lifetimes of variables bound with let statements in a function body. Because of this, device.rs fails to compile against newer rustc nightlies. This implements a simple workaround that binds the result of the match in `request_code` to a local variable before returning it. This allows it to have the same lifetime as `req` in one of the previous let bindings.
Triage: no change, at least for the example provided by @theemathas |
This looks like a duplicate of #33490 - on MIR it would be a segfault, on trans it (incorrectly) isn't. |
@arielb1 This is a bug about a compilation error, not a runtime failure, so I don't think this is a duplicate of that issue (which was also filed a year and a half after this one). |
The issues have the same root cause - borrowck/MIR have a notion of destruction order that makes this code obviously wrong. Trans uses a different destruction order, but that is problematic. |
#33490 is closed but this issue still exists in nightly. Without the |
#33490 seems open to me? |
Oops, I meant that comments like #33490 (comment) claimed that MIR now behaves correctly and that only old trans was still broken. |
Adding anything after the match (like
;
or()
) causes the error to go away.cc @pnkfelix
The text was updated successfully, but these errors were encountered: