Nightly regression in Structual Eq check for match

[CeleritasCelery]

Code

I tried this code:

#[derive(PartialEq)]
pub(crate) struct NonMatchable ();

impl Eq for NonMatchable {}

#[derive(PartialEq, Eq)]
pub(crate) enum Enum {
    A(NonMatchable),
    B(*const u8),
}

impl Enum {
    const CONST: Enum = Enum::B(std::ptr::null());
}

fn main() {
    let _ = match Enum::CONST {
        Enum::CONST => 0,
        _ => 1,
    };
}

The above code compiles fine on beta and stable, but fails on the latest nightly. It used to pass on nightly too (last I tested it). The errors is this:

error: to use a constant of type `NonMatchable` in a pattern, `NonMatchable` must be annotated with `#[derive(PartialEq, Eq)]`
  --> src/main.rs:18:9
   |
18 |         Enum::CONST => 0,
   |         ^^^^^^^^^^^
   |
   = note: the traits must be derived, manual `impl`s are not sufficient
   = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralEq.html for details

The error is claiming that we are using NonMatchable in the pattern when we are not. Interestingly if we change the value of Enum::B to be something other then a pointer, this passes (though that should not make a difference). Also if we don't use a constant but instead match on std::ptr::null() directly, it passes as well. We only see this issue in the nightly compiler when we both using a constant and the variant in the constant is a pointer. Unless I am misunderstanding something here, this should not be an error.

Version it worked on

It most recently worked on:

binary: rustc
commit-hash: 489647f984b2b3a5ee6b2a0d46a527c8d926ceae
commit-date: 2023-10-21
host: aarch64-apple-darwin
release: 1.74.0-beta.4
LLVM version: 17.0.3

Version with regression

rustc --version --verbose:

binary: rustc
commit-hash: a2f5f9691b6ce64c1703feaf9363710dfd7a56cf
commit-date: 2023-11-02
host: aarch64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.4

[bvanjoi]

I believe there has been a regression as per the pull request #116522, and I plan to investigate it further at a later time.

[apiraino]

bisection seems to confirm PR #116522 thanks @bvanjoi for looking into that!

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high -needs-triage

[lqd]

That does indeed bisect to #116522