Spawned off of investigation of issue #62307 and PR #55837

We currently allow constants that are empty arrays of any type to be used as patterns in match. We allow this regardless of whether they are an array of an ADT that does not derive PartialEq/Eq

This may be a feature or a bug depending on one's perspective.

Here is an example of the behavior in question (play):

struct B(i32);

const B0: [B; 0] = [];

//#[derive(PartialEq, Eq)] // can't uncomment b/c B doesn't impl PartialEq+Eq.
struct UhOh([B; 0]);

const _UH_OH: UhOh = UhOh(B0);

fn main() {
    match [] {
        B0 => { println!("B0 matched []"); }
    }

    match UhOh([]) {
        UhOh(B0) => { println!("UhOh(B0) matched UhOh([])"); }
    }

    #[cfg(this_wont_compile_without_derive_of_partial_eq_and_eq)]
    match UhOh([]) {
        _UH_OH => { println!("_UH_OH matched UhOh([]])"); }
    }
}

To be clear: This behavior might be fine.

It is just a little weird, because on other uses of consts in patterns, we do tend to require that their types derive PartialEq and Eq

• the use of the derive is asserted by the presence of #[structural_match]; see Restrict constants in patterns rfcs#1445).
• Update: there are other exceptions where PartialEq is not required for a const in a pattern, namely for for <'a> fn(&'a T); see Function pointer docs may need updating #46989 (comment) )

But we can treat an empty array as an exceptional case here, if that's what people want.

• If this is the behavior that we do want, then lets make sure we have a test encoding it.
• It this is not the behavior that we want, then we can fix it (presumably in a similar manner to how I am going about fixing issue structural_match bug: deep refs like & &B leak use of PartialEq #62307).