Manually order DefId on 64-bit big-endian

[cuviper]

DefId uses different field orders on 64-bit big-endian vs. others, in
order to optimize its Hash implementation. However, that also made it
derive different lexical ordering for PartialOrd and Ord. That
caused spurious differences wherever DefIds are sorted, like the
candidate sources list in report_method_error.

Now we manually implement PartialOrd and Ord on 64-bit big-endian to
match the same lexical ordering as other targets, fixing at least one
test, src/test/ui/methods/method-ambig-two-traits-cross-crate.rs.

[rust-highfive]

r? @fee1-dead

(rust-highfive has picked a reviewer for you, use r? to override)

[cjgillot]

Relying on the DefId ordering is a source of incr-comp bug. It would be more interesting to remove this dependency and make the test rely on some other order, like the one of source code, or of spans.

[cuviper]

Are there any plans to remove DefID ordering altogether? Because this PR is just making the status quo more consistent.

[cjgillot]

Yes, there is #90317, and #92233, which is a prerequisite.

[cuviper]

OK, well that looks like a huge effort, but it can easily drop the changes I'm making here when that goes through.

It would be more interesting to remove this dependency and make the test rely on some other order, like the one of source code, or of spans.

As for this, I think the test doesn't really care about order at all, just that it needs to be reproducible enough for UI to match. I can look at other more-stable options.

[fee1-dead]

@bors r+

[bors]

📌 Commit fb5002d has been approved by fee1-dead

It is now in the queue for this repository.