@WG-prioritization/alerts issue #74713 has been requested for prioritization.

Procedure

• Priority?
• Regression?
• Notify people/groups?
• Needs I-nominated?

ICE on stable hence prioritised

This is a slight variation of #56445 and will probably be fixed while working on min_const_generics.

We can probably either close this as a duplicate or also assign P-high as it is a slightly different example, even if the cause should be identical

IIUC this only happens in a failing path? Or am I missing something?

If this only happens in a failing path then we should probably assign P-medium or even P-low given how old this regression is

it's complicated

so we don't supply the parent generics to arrays in function definitions and where bounds at all, so in this case it can currently never work

fn bug<'a>() {
    let _ = [(); {
        let _: &'a ();
        3
    }];
}

has the same ICE but should theoretically compile rn because we do allow the parent generics in repeat expressions and enum discriminants

So that's plainly a bug with const generics rn

has the same ICE but should theoretically compile rn because we do allow the parent generics in repeat expressions and enum discriminants

I'm assuming it should compile with #![feature(const_generics)]?

yeah

I think it should compile even without #![feature(const_generics)]

Because it is used for an array?

it's complicated

^

lcnr said:

it's complicated

^

I'm not ready for const generics yet then x)

What would you suggest? Do you think this should be P-high?

the repeat length is a concrete value here, so that should be just be equal to [(); 3] on stable

Hmm, so without considering how we might fix this, this is still an ICE which is fairly easy to hit so it should be P-high

Issue #74713's prioritization request has been removed.