Checking a `&PathBuf` and a `&str` for equality leads to a stack overflow

[fmease]

Reproducer (nightly 1.91):

fn main() {
    _ = &std::path::PathBuf::from("x") == "-";
}

or

fn main() {
    _ = "-" == &std::path::PathBuf::from("x");
}

When run, it leads to a stack overflow. Output in debug mode (hangs in release):

thread 'main' (157) has overflowed its stack
fatal runtime error: stack overflow, aborting

_ = std::path::Path::new("x") == "-"; does not reproduce this stack overflow.
Neither does this: _ = &std::path::PathBuf::from("x") == std::path::Path::new("-");.

This might be related to the recent addition of PartialEq<str> for Path, PartialEq<str> for PathBuf and friends on nightly (1.91).

---

rustc 1.91.0-nightly (51ff89506 2025-09-02)
binary: rustc
commit-hash: 51ff895062ba60a7cba53f57af928c3fb7b0f2f4
commit-date: 2025-09-02
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

Also reproduces on the playground (nightly).

[fmease]

I have no clue what's going on, I just stumbled upon this in a project of mine.

[fmease]

I've classified this as a bug because that seems to be bad pitfall / usability problem of PartialEq<str> for Path if it's indeed related to that.

I'm guessing we're indefinitely deref'ing the LHS? Why though? How?

[fmease]

Ah, I think I found it. This looks like it's calling itself recursively:

#[stable(feature = "eq_str_for_path", since = "CURRENT_RUSTC_VERSION")]
impl cmp::PartialEq<str> for PathBuf {
    #[inline]
    fn eq(&self, other: &str) -> bool {
        &*self == other
    }
}

The &*self stays a &PathBuf IINM (and doesn't become a &Path), needs to be &**self or similar.

[fmease]

These two impls need to be fixed before this reaches beta/stable.

[fmease]

cc @Kixunil (#140956)