RFC 2203 does not work for `Vec::new`

[ecstatic-morse]

RFC 2203 specifically calls out Vec::new as a motivating example, however this does not work on the current nightly.

fn main() {
    let _: [Vec<i32>; 4] = [Vec::new(); 4];
}

There are two reasons for this. First, promotion in array repeat expressions currently uses the "implicit" rules for promotability, which forbids promotion of function calls without #[rustc_promotable]. Second, the result of Vec::new() is marked as NeedsDrop since Vec<T> is Drop, which disqualifies it from promotion, even in an explicit context.

cc #49147

[Centril]

cc @eddyb @RalfJung @oli-obk @nikomatsakis

[eddyb]

The NeedsDrop thing (maybe) sounds like a bug in the old promotion logic.
The new logic in #63812 doesn't look at NeedsDrop at all, except for Candidate::Ref.

[ecstatic-morse]

A comment in qualify_consts:

// Any qualifications, except HasMutInterior (see above), disqualify
// from promotion.
// This is, in particular, the "implicit promotion" version of
// the check making sure that we don't run drop glue during const-eval.

I think explicit (non-Candidate::Ref) promotion contexts should indeed promote values with NeedsDrop, which is implied by the second half of the comment, but not the way things work currently.

If everyone is comfortable with this, I will add it to the rules for promotability.

[RalfJung]

@Centril or @nikomatsakis mentioned that we might at some point even allow using run-time expressions for array repeats... in the light of that it might not be a good idea to use the "explicit" rules for promotability. "explicit" is only okay if code would fail to compile when not promoted.

[ecstatic-morse]

If the type of the array element is Copy, failure to promote the initializer does not imply the code will fail to compile, so I think this argument applies to the current situation as well. That said, I don't know if we have to be quite that strict when deciding to use the explicit rules. We don't need to extend the lifetime of promoted expressions like we do for rvalue-static promotion.

[RalfJung]

If the type of the array element is Copy, failure to promote the initializer does not imply the code will fail to compile

Wait, what? I was under the impression that we first check Copy and only if that fails, force promotion. For us to use explicit promotion rules, failure to promote must imply failure to compile.

That said, I don't know if we have to be quite that strict when deciding to use the explicit rules. We don't need to extend the lifetime of promoted expressions like we do for rvalue-static promotion.

I think we do. The reason we are so strict is that code might do things (in particular, code inside const fn in other crates) that fails during CTFE but would succeed during run-time -- there might be "unconst" operations and they might occur only for certain arguments. These are things like observing the base address of a pointer, or using transmutes/unions to get around CTFE limitations. If that happens, that's bad enough, but we do not want that to lead to a compilation failure for a crate that could have compiled fine had we not promoted.

So, the strict stanza "failure to promote must imply failure to compile" has nothing to do with lifetimes or drop or so. It's all about not breaking people's ability to compile their code.

[ecstatic-morse]

Wait, what? I was under the impression that we first check Copy and only if that fails, force promotion. For us to use explicit promotion rules, failure to promote must imply failure to compile.

For non-Copy arrays, failure to promote does imply failure to compile. From this perspective, for Copy arrays, promotion is not involved at all. If we were to make array initialization occur unconditionally at runtime, promotion would not be involved ever. In this scenario as well as the status quo, we fail to compile if we ever try to promote the initializer and fail, so I think the requirements for explicit promotion are met here. The fact that we only sometimes try to promote the initializer makes this weird.

If you're not convinced by the above (I'm not entirely convinced either), we should switch to the following rules for promotability and make Vec::new #[rustc_promotable]:

Promotion Context	Allows Drop	Allows const fn calls
&expr	❌	❌
[expr; 4]	✔️	❌
simd_shuffle(expr)	❔	✔️

I don't think it matters whether we allow Drop for #[rustc_args_required_const], so we might as well forbid it. This would mean that every promotion context has slightly different rules around promotability, so the "implicit"/"explicit" distinction would no longer be enough.

[eddyb]

From this perspective, for Copy arrays, promotion is not involved at all.

Did we fix this though? I forget if we actually added that check.

[ecstatic-morse]

@eddyb You're correct. On nightly, all array initializers are promoted if the feature is enabled (look at the generated MIR).