Bogus "warning: dataflow bug??? moving out of type with dtor" for field assignments.

[eddyb]

When assigning a non-Copy field of a structure which has a destructor, the drop of the field before writing the new value causes a warning in the MIR dataflow code:

struct Foo(String);

impl Drop for Foo {
    fn drop(&mut self) {}
}

fn main() {
    let mut f = Foo(String::from("foo"));
    f.0 = String::from("bar");
}

test.rs:8:9: 8:14 warning: dataflow bug??? moving out of type with dtor DropCtxt { span: test.rs:8:9: 8:14, scope: ScopeId(3), is_cleanup: true, init_data: , lvalue: var0, path: MovePathIndex(NonZero(1)), succ: bb1, unwind: None }
test.rs:8     let mut f = Foo(String::from("foo"));
                  ^~~~~

Seeing how this is supported in stable Rust, the warning seems superfluous and the resulting code runs without a hitch, although I'm not sure if there any subtle problems around unwinding.

cc @arielb1 @pnkfelix

[nikomatsakis]

cc me

[pnkfelix]

My current intuition is that the gather_moves pass on DropAndReplace on a Projection (e.g. var0.0 here) on its own is creating a separate MovePath for the replaced thing, but maybe we should not do this, since it is causing us to allocate a separate drop flag for var0.0 even though such a flag can never have a state distinct from the state for the drop flag for var0 itself.

Update: Then again, maybe its simpler to leave gather_moves alone; otherwise it seems like gather_moves would need to deal with conditionally looking up the MovePath in question depending on whether code elsewhere had created one... (or alternatively, gather_moves could solely filter out creating a MovePath when some parent path has a destructor attached).

[pnkfelix]

Or maybe the right approach, which has the advantage of being isolated to elaborate_drops, would be to change lvalue_contents_are_tracked to return false when the parent lvalue's type has a Drop impl.

[pnkfelix]

(I have a patch for this, I'll put up a PR shortly.)

[pnkfelix]

Fixed by PR #34109