-
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
Misleading error with Drop and lifetime parameters #17858
Comments
I think the error message may just be a little misleading, if you opt into #![feature(unsafe_destructor)]
struct S<'a>(&'a T);
struct T;
#[unsafe_destructor]
impl<'a> Drop for S<'a> {
fn drop(&mut self) {}
}
fn main() {
let _ = S(&T);
} |
It does but I don't quite understand why the compiler rejects the program. Does the presence of the lifetime make it unsound? |
Right now the compiler's handling of lifetimes and destructors aren't quite sound in all cases. For example, in your example, it should be required that the destructor of Whereas, in this example (which compiles today), the destructor for #![feature(unsafe_destructor)]
struct S<'a>(&'a T);
struct T;
impl<'a> S<'a> {
fn foo(&self) {}
}
#[unsafe_destructor]
impl<'a> Drop for S<'a> {
fn drop(&mut self) {
println!("dropping S");
}
}
impl Drop for T {
fn drop(&mut self) {
println!("dropping T");
}
}
fn main() {
{
println!("before!");
let t = T;
S(&t).foo()
};
println!("after!");
}
|
And for a real world use case, you can see my comment which uses a standard |
Thanks Alex, that makes perfect sense. Should I close the issue? |
I think the error message could still use some improvement (mention lifetime parameters, for example), so I'm ok leaving this open to track that. |
There is something I don't understand about the example though: We explicitly specify that the lifetime of the After all, it appears there might be a problem with either expressiveness of lifetimes, or with the way destructors are handled, which is exactly what you said :) : "Right now the compiler's handling of lifetimes and destructors aren't quite sound in all cases.". Good I arrived at the same conclusion. Another concern of mine is also stated in #11406/#8861: there may be an inflationary use of |
@Byron this is exactly the topic of rust-lang/rfcs#769 , which has a prototype implementation (see #21972) essentially ready to land (and should land for 1.0), and that should remove the unsoundness discussed here. |
I suspect this issue can be closed. Error
( |
Agree with @nham |
feat: render patterns in params for hovering Fix rust-lang#17858 This PR introduces an option to [hir-def/src/body/pretty.rs](https://github.com/rust-lang/rust-analyzer/blob/08c7bbc2dbe4dcc8968484f1a0e1e6fe7a1d4f6d/crates/hir-def/src/body/pretty.rs) to render the result as a single line, which is then reused for rendering patterns in parameters for hovering.
It's not clear to me why this program gets rejected.
The text was updated successfully, but these errors were encountered: