`derive(PartialEq)` on enums is unsound with user-defined attribute macros.

[theemathas]

dep/src/lib.rs:

use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn discard(_: TokenStream, _: TokenStream) -> TokenStream {
    TokenStream::new()
}

src/main.rs

#![allow(unused)]

#[derive(PartialEq)]
#[dep::discard]
enum Thing {
    One(i32),
    Two(i32),
}

enum Thing {
    One(i32),
    Two(i32),
    Three(i32),
}

fn main() {
    Thing::Three(1) == Thing::Three(1);
}

The above code causes undefined behavior in safe code. Miri output below:

error: Undefined Behavior: entering unreachable code
  --> src/main.rs:3:10
   |
 3 | #[derive(PartialEq)]
   |          ^^^^^^^^^ Undefined Behavior occurred here
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
   = note: BACKTRACE:
   = note: inside `<Thing as std::cmp::PartialEq>::eq` at src/main.rs:3:10: 3:19
note: inside `main`
  --> src/main.rs:17:5
   |
17 |     Thing::Three(1) == Thing::Three(1);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

This happens because the derive(PartialEq) macro expands to code that assumes that the enum has exactly two variants. However, the discard macro discarded the enum definition seen by PartialEq, so the expanded code instead refers to the second definition of Foo, which has three variants.

Output of cargo +nightly rustc -- -Zunpretty=expanded:

#![feature(prelude_import)]
#![allow(unused)]
#[macro_use]
extern crate std;
#[prelude_import]
use std::prelude::rust_2024::*;

#[automatically_derived]
impl ::core::marker::StructuralPartialEq for Thing { }
#[automatically_derived]
impl ::core::cmp::PartialEq for Thing {
    #[inline]
    fn eq(&self, other: &Thing) -> bool {
        let __self_discr = ::core::intrinsics::discriminant_value(self);
        let __arg1_discr = ::core::intrinsics::discriminant_value(other);
        __self_discr == __arg1_discr &&
            match (self, other) {
                (Thing::One(__self_0), Thing::One(__arg1_0)) =>
                    __self_0 == __arg1_0,
                (Thing::Two(__self_0), Thing::Two(__arg1_0)) =>
                    __self_0 == __arg1_0,
                _ => unsafe { ::core::intrinsics::unreachable() }
            }
    }
}

enum Thing { One(i32), Two(i32), Three(i32), }

fn main() { Thing::Three(1) == Thing::Three(1); }

This bug could plausibly be hit in real code if an attribute macro adds a new variant to an enum.

See also #148277

Meta

rustc --version --verbose:

rustc 1.93.0-nightly (b15a874aa 2025-11-02)
binary: rustc
commit-hash: b15a874aafe7eab9ea3ac2c1d59c7b03e1425027
commit-date: 2025-11-02
host: aarch64-apple-darwin
release: 1.93.0-nightly
LLVM version: 21.1.3

[theemathas]

The unreachable call was added in 0eeb14e

[workingjubilee]

Prioritizing per my reasoning here: Zulip discussion.

@rustbot label: -I-prioritize +P-critical

( pulled nom after discussion )

It may be appropriate to revise downward later? I don't know.

This is the "derive is purely additive but sees code that may be non-additive" problem cited by zerocopy as an unsoundness risk. So, as a known issue that plagues ecosystem crates, I suppose it was only a matter of time before this problem came home to roost.

I have offered the following possible solution before for this problem, though I have not investigated how effective it is (nor how easy to implement!): Allow some derive macros to be ordered after attribute macros in expansion, even if the typical expansion ordering would expand the derive macro first. I have been informed that some macros would find this undesirable, so this could be an opt-in property of the macro. And this is a builtin, so we could apply such an exception in our logic regardless.

Obviously, a simpler solution that is probably much easier to implement, yet regresses codegen for many enums, would be to simply remove the unreachable expansions. This is probably not the solution we would prefer but we may decide it is better to first stop emitting incorrect code and then fix the optimization later.

[theemathas]

Here's a realistic code snippet that, while it doesn't lead to UB, it does lead to incorrect run time behavior.

// Tested with enum_dispatch version 0.3.13
use enum_dispatch::enum_dispatch;

#[derive(PartialEq)]
struct A(i32);
#[derive(PartialEq)]
struct B(i32);

#[derive(PartialEq)]
#[enum_dispatch(WhatTrait)]
enum What {
    A,
    B,
}

#[enum_dispatch]
trait WhatTrait {}
impl WhatTrait for A {}
impl WhatTrait for B {}

fn main() {
    if What::A(A(1)) == What::A(A(2)) {
        println!("what");  // This line is executed
    }
}

Output of `cargo +nightly rustc -- -Zunpretty=expanded`

#![feature(prelude_import)]
#[macro_use]
extern crate std;
#[prelude_import]
use std::prelude::rust_2024::*;
use enum_dispatch::enum_dispatch;

struct A(i32);
#[automatically_derived]
impl ::core::marker::StructuralPartialEq for A { }
#[automatically_derived]
impl ::core::cmp::PartialEq for A {
    #[inline]
    fn eq(&self, other: &A) -> bool { self.0 == other.0 }
}
struct B(i32);
#[automatically_derived]
impl ::core::marker::StructuralPartialEq for B { }
#[automatically_derived]
impl ::core::cmp::PartialEq for B {
    #[inline]
    fn eq(&self, other: &B) -> bool { self.0 == other.0 }
}

enum What { A(A), B(B), }
#[automatically_derived]
impl ::core::marker::StructuralPartialEq for What { }
#[automatically_derived]
impl ::core::cmp::PartialEq for What {
    #[inline]
    fn eq(&self, other: &What) -> bool {
        let __self_discr = ::core::intrinsics::discriminant_value(self);
        let __arg1_discr = ::core::intrinsics::discriminant_value(other);
        __self_discr == __arg1_discr
    }
}

trait WhatTrait {}
impl ::core::convert::From<A> for What {
    fn from(v: A) -> What { What::A(v) }
}
impl ::core::convert::From<B> for What {
    fn from(v: B) -> What { What::B(v) }
}
impl ::core::convert::TryInto<A> for What {
    type Error = &'static str;
    fn try_into(self)
        ->
            ::core::result::Result<A,
            <Self as ::core::convert::TryInto<A>>::Error> {
        match self {
            What::A(v) => { Ok(v) }
            What::B(v) => { Err("Tried to convert variant B to A") }
        }
    }
}
impl ::core::convert::TryInto<B> for What {
    type Error = &'static str;
    fn try_into(self)
        ->
            ::core::result::Result<B,
            <Self as ::core::convert::TryInto<B>>::Error> {
        match self {
            What::B(v) => { Ok(v) }
            What::A(v) => { Err("Tried to convert variant A to B") }
        }
    }
}
impl WhatTrait for What {}
impl WhatTrait for A {}
impl WhatTrait for B {}

fn main() {
    if What::A(A(1)) == What::A(A(2)) {
        { ::std::io::_print(format_args!("what\n")); };
    }
}

My quick attempt at a github code search finds at least two repos that seem to be affected by this exact problem:

• https://github.com/literalplus/sheet-shark/blob/bfed4d17e1637cd54386546580fab535f08c04d3/src/components/home/editing.rs#L25
• https://github.com/nms-scribe/nms-scribe.github.io/blob/d8bb319eb34ce6489a6edb9116f71871206d55b3/_tools/publish.rs#L1330