-
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
drop-tracking: ICE when using default struct update syntax #98476
Comments
Strangely, this has to be a type with an allocator - using |
UI test (also slightly reduced - turns out the relevant part here is having a custom Drop): // build-pass
// edition:2018
// compile-flags: -Zdrop-tracking=y
fn main() {
let _ = foo();
}
async fn from_config(x: Config) {
async {}.await;
drop(x);
}
async fn foo() {
from_config(Config {
nickname: NonCopy,
..Default::default()
})
.await;
}
#[derive(Default)]
struct NonCopy;
impl Drop for NonCopy {
fn drop(&mut self) {}
}
#[derive(Default)]
struct Config {
nickname: NonCopy,
} |
This has to do with the fact that the temporary which serves as the base expr of the struct, namely This ICEs similarly if we have something like |
@compiler-errors I'm not sure I follow - why do we have a live |
Well, we have a partially live We need to keep the |
Thanks! That makes sense to me. Here's a reproduction with just generators (no futures) and using multiple fields instead of ..Default::default(): // build-pass
// edition:2018
// compile-flags: -Zdrop-tracking=y
#![feature(generators)]
fn main() {
let _ = foo();
}
fn foo() {
|| {
yield drop(Config {
nickname: NonCopy,
b: NonCopy2,
}.nickname);
};
}
#[derive(Default)]
struct NonCopy;
impl Drop for NonCopy {
fn drop(&mut self) {}
}
#[derive(Default)]
struct NonCopy2;
impl Drop for NonCopy2 {
fn drop(&mut self) {}
}
#[derive(Default)]
struct Config {
nickname: NonCopy,
b: NonCopy2,
} |
@rustbot label +AsyncAwait-Triaged |
…impl is used across an await Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which was not true: when the field had a type with a manual `Drop` impl, the drop becomes observable and has to be dropped after the await instead. For reasons I don't understand, this also fixes another error crater popped up related to type parameters. rust-lang#98476
…-errors Fix drop-tracking ICE when a struct containing a field with a significant drop is used across an await Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which was not true. Fixes rust-lang#98476. Also fixes rust-lang#98477, I think because the parent HIR node for type variables is the whole function instead of the expression where the variable is used. r? `@eholk`
cc #97331, @eholk. Minimized from https://crater-reports.s3.amazonaws.com/pr-97334/try%23615edd3ad1cf6871c977dc900317cb6c2070fd6b/gh/AsuMagic.markov-irc/log.txt in the crater run for #97334.
Code
Meta
rustc --version
: 615edd3ad1cf6871c977dc900317cb6c2070fd6bError output
Backtrace
The text was updated successfully, but these errors were encountered: