Frank Steffahn

@sfackler Let me repeat what I already stated: > focus on the final paragraph in the quote above and that final paragraph is > Note that these requirements mean that...

The solution that `PartialEq` takes isn’t perfect either. The following example is a bit artificial because I couldn’t find or come up with a real/realistic one (yet). According to those...

This `PartialEq` documentation also doesn’t disallow something like ```rs struct A(u8); struct B(u8); struct C(u8); struct D(u8); impl PartialEq for A { fn eq(&self, other: &B) -> bool { self.0...

In any case, I agree that the conditions as in `PartialEq` are *better* than before and better than the ones in `PartialOrd`.

> So the point is that if b == a would type-check then it would be required to hold (and then a != b would be forbidden), but there is...

You don’t need any flags anymore. I believe since `tag-raw-pointers` is now on by default AFAIR.

Thanks for writing this issue. I just wanted to bisect an ASM output issue, and thanks to your information here, it was really straightforward 🙂

There’s another issue with issues mentioned in PR descriptions. These get turned into commit messages for the auto-merge / rollup-merge commits. See https://github.com/rust-lang/homu/pull/145#issuecomment-865031079.

I guess rollup merge commit messages are relevant, too…

Looking at something like the incorrect backlinks appearing in https://github.com/rust-lang/rust/issues/7235, the “successful merges” list is relevant, too.