Double-drops when control jumps out of borrow of slice literal construction

[pnkfelix]

(this is related to #30018, but it is also a distinct problem in its own right.)

We appear to be creating copies of values that should be moved when doing slice literal construction.

The copies can be observed because double-drop (of the same abstract value) can occur when there is a break of control out of the slice literal during evaluation of one of the elements.

Here is an example (playpen):

struct D(&'static str);

impl Drop for D {
    fn drop(&mut self) {
        println!("Dropping D({})", self.0);
    }
}

fn main() {
    println!("Start");
    loop {
        let _r = &[D("1"),
                   D("2"),
                   { let _tmp = D("3"); break; },
                   D("4")];
    }
    println!("Finis");
}

outputs (in release mode):

Start
Dropping D(3)
Dropping D(2)
Dropping D(1)
Dropping D(1)
Dropping D(2)
Finis

The crucial point is that we see double drops of D(1) and D(2) in the output above. This would correspond, at least in theory, to deallocating a backing buffer multiple times -- that is, it is wrong. (Types like Vec probably defend themselves against such an attack since they currently use unsafe_no_drop_flag and thus should have an embedded drop flag state that it is maintaining itself, but other types that implement Drop do not necessary take that tack.)

(In debug mode there is a sigtrap at the end of that example; that is due to #30018, but again, that is not this ticket.)

[pnkfelix]

One way to solve this problem would be to set the drop-flags to "dropped" after running the destructors on each of the D's the first time through.

However, I am a little surprised by the idea that this would be necessary; in particular, I would have thought that the array of D constructed via alloca would itself have no other cleanup scope associated with it, and so I don't know why the generated code thinks/knows that it needs to run the destructor for that array

---

Update: The previous paragraph was wrong: the cleanup for the array itself is indeed necessary, since we might panic after we've actually finished all of the elements of the array itself. (The regression test I added with PR #30823 covers this case.) I don't know if there's any way to delay the scheduling of the array cleanup until after it has been entirely initialized ... that is, some way to make so that the array cleanup is not a parent scope during the evaluation of the individual elements... anyway, the easy way to get around this is to do what I said above: Set the drop-flags to "dropped" when dropping each of the Ds' if control breaks in the midst of the array construction. (That is what PR #30823 does)