ICE resolving non-existent PartialEq::Eq from match of const

[pnkfelix]

(Spawned off of #61188 (comment) )

Sometimes the code-generation for pattern-matching a const will generate a invocation of PartialEq::eq (rather than unfolding the structure of that constant inline, which is the usual compilation strategy used in rustc currently...)

The difference between unfolding inline and invoking PartialEq::eq is not meant to be observable, because of RFC 1445 (c.f. #31434): "Restrict constants in patterns"

However, there are cases where rustc's static analysis of the pattern itself was not thorough enough, and it would let patterns through that do end up invoking PartialEq::eq on constants that do not even implement PartialEq in the first place.

We had been relying on the structural-match checking to catch such cases, where we would first run the structural match check, and if we found an ADT that was a non-structural-match, then we would then check if the const in question even implements PartialEq.

But that strategy, of a delayed check for PartialEq, does not suffice in every case. Here is an example, taken from @matthewjasper 's comment linked above:

#![deny(indirect_structural_match)]

#[derive(PartialEq, Eq)]
enum O<T> {
    Some(*const T), // Can also use PhantomData<T>
    None,
}

struct B;

const C: &[O<B>] = &[O::None];

pub fn foo() {
    let x = O::None;
    match &[x][..] {
        C => (),
        _ => (),
    }
}

I had been tagging the above test case as being part of #61188, but at this point I think it is confusing matters, because the code/comments/commit messages say things like "this does not yet fix #61188" and it is ambgious whether that message refers to the original bug described by #61188, or the subsequent issue pointed out by @matthewjasper linked above.

So I am allocating a fresh issue to track the matter here.

[pnkfelix]

todo: check how PR #66120 #67088 handles this...