simplify SourceID Ord/Eq

[Eh2406]

What does this PR try to resolve?

This is a followup to #14800. Like that PR, this is a small incremental change that does not pull its own weight. If this PR is accepted, the next PR will unlock large performance wins. I am not posting them together because the logic of why this PR is correct is subtle and deserves to be discussed and reviewed without unrelated code changes.

How should we test and review this PR?

All tests pass on all commits. This should be reviewed one commit at a time.

Additional information

I pushed one commit at a time, so that CI can confirm that the assert (in the first commit) is never hit.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

Potential risk:

If someone has two alternate registry hosted on github whose name has one of the weird languages where a < b does not imply a.to_lower() < b.to_lower() (we did this normalization in CanonicialUrl for only github.com domain), then the package order in the lockfile file could switch between different versions of Cargo.

Though this is pretty niche and I doubt it impacts any real world use case.

[weihanglo]

@rfcbot fcp merge

I propose to the team to merge this. See the comment in 2a9527b for detailed explanation.

tl;dr

• Cargo can never have two SourceIds with everything the same except for the url field, because when interning, we hash only kind, precise, and canonical_url, not url.
• One of the risks we can think of is described in simplify SourceID Ord/Eq #14980
• The other one might be a path dependency having a path ending with .git got chopped off, making the package order different in lockfile. I also think this is a weird use case we can ignore.

If there is any implication we're missing here, please call it out!

[rfcbot]

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @Rustin170506
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Eh2406]

Note that all of the risks identified so far involve the implications to ord and the performance benefits mostly relate to eq. If more risks are found, or the risks related to ord are to painful this PR can be updated to leave ord as is and instead do the comparable thing directly on eq. I prefer the code simplicity of eq delegating to ord, but opinions can legitimately vary.

[Rustin170506]

If someone has two alternate registry hosted on github whose name has one of the weird languages where a < b does not imply a.to_lower() < b.to_lower()

May I ask, do you have a real example of this?

[weihanglo]

I don't, unfortunately. I don't even know if there is a language has such odd upper/lowercase comparison. CJK might potentially maybe?

cc @Eh2406, is it possible to create one real example on your side?

[Eh2406]

I only speak English. So I've no idea how realistic these examples are. But some googling found this list https://stackoverflow.com/questions/67106784/why-is-upper-casing-not-enough-for-case-insensitive-comparison and with the help of some intelligent auto complete here are sum reproducers https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f4bc9bc63fa18a63f2e503442521e82c

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[weihanglo]

Thanks Jacob.

Since we have reached a consensus, going to merge this now. I don't think waiting for an entire 10-day FCP will make any difference. If there is a real use case, only when the change hits nightly and people start using it will we know.