`MarkerEq` doesn't specialize on unsized types

[Gaming32]

If you write the following code, the a == b will not specialize to pointer comparisons purely because str is unsized. If a String were used, the address would be compared.

let a: Rc<str> = "example".into();
let b = Rc::clone(a);
a == b;

You can see an example on Godbolt here: https://godbolt.org/z/qeKMYvPo1.

The bug itself narrows down to, as far as I can see, the following code using T: Eq instead of T: ?Sized + Eq. Notably the code just below uses ?Sized + MarkerEq, which will never occur unless a std type were to manually implement MarkerEq for some reason, leading me to believe that this is likely an unintended for this bound to fail on unsized types.

Meta

rustc --version --verbose:

rustc 1.94.0 (4a4ef493e 2026-03-02)
binary: rustc
commit-hash: 4a4ef493e3a1488c6e321570238084b38948f6db
commit-date: 2026-03-02
host: x86_64-pc-windows-msvc
release: 1.94.0
LLVM version: 21.1.8

[theemathas]

I think that making this change is probably incorrect, but I'm not sure.

Consider the following, which I believe is a technically legal implementation of Eq:

trait Trait {}

impl PartialEq for dyn Trait + '_ {
    fn eq(&self, other: &Self) -> bool {
        // compare both the data ptr and vtable ptr
        std::ptr::eq(self, other)
    }
}

impl Eq for dyn Trait + '_ {}

It would be possible for two Rcs to point to the same data, and yet have different vtables, so two such Rcs must compare as unequal.

[Gaming32]

Would it be sufficient to change RcEqIdent to use ptr::eq instead of ptr::addr_eq as well then?

[Jules-Bertholet]

It's not just dyn; arguably, the following should be sound:

use std::rc::Rc;
fn main() {
    let a: Rc<[()]> = Rc::new([(); 3]);
    let ptr: *const () = Rc::into_raw(a.clone()).cast();
    let b: Rc<[()]> = unsafe { Rc::from_raw(core::ptr::slice_from_raw_parts(ptr, 42)) };
    assert!(a != b);
}