Modify MIR building to drop repeat expressions with length zero by JakobDegen · Pull Request #95953 · rust-lang/rust (original) (raw)

Closes #74836 .

Previously, when a user wrote [foo; 0] we used to simply leak foo. The goal is to fix that. This PR changes MIR building to make [foo; 0] equivalent to { drop(foo); [] } in all cases. Of course, this is a breaking change (see below). A crater run did not indicate any regressions though, and given that the previous behavior was almost definitely not what any user wanted, it seems unlikely that anyone was relying on this.

Note that const generics are in general unaffected by this. Inserting the extra drop is only meaningful/necessary when foo is of a non-Copy type, and array repeat expressions with const generic repetition count must always be Copy.

Besides the obvious change to behavior associated with the additional drop, there are three categories of examples where this also changes observable behavior. In all of these cases, the new behavior is consistent with what you would get by replacing [foo; 0] with { drop(foo); [] }. As such, none of these give the user new powers to express more things.

No longer allowed in const (breaking):

const _: [String; 0] = [String::new(); 0];

This compiles on stable today. Because we now introduce the drop of String, this no longer compiles as String may not be dropped in a const context.

Reduced dataflow (non-breaking):

let mut x: i32 = 0; let r = &x; let a = [r; 0]; x = 5; let _b = a;

Borrowck rejects this code on stable because it believes there is dataflow between a and r, and so the lifetime of r has to extend to the last statement. This change removes the dataflow and the above code is allowed to compile.

More const promotion (non-breaking):

let _v: &'static [String; 0] = &[String::new(); 0];

This does not compile today because String having drop glue keeps it from being const promoted (despite that drop glue never being executed). After this change, this is allowed to compile.

Alternatives

A previous attempt at this tried to reduce breakage by various tricks. This is still a possibility, but given that crater showed no regressions it seems unclear why we would want to introduce this complexity.

Disallowing [foo; 0] completely is also an option, but obviously this is more of a breaking change. I do not know how often this is actually used though.

r? @oli-obk