Stop sorting Spans' SyntaxContext, as that is incompatible with incremental

[oli-obk]

work towards #90317

Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.

r? @cjgillot

[cjgillot]

This needs a comment for macro expansions.
Side note: this Ord impl is not consistent with the derived impl for PartialEq. Should we fix the latter?

[oli-obk]

What do you think about ensuring that for equal (including the sort-ignored fields) SpanDatas we just return Ordering::Equal, and only sort the others?

[cjgillot]

That's not consistent either.
The a == b implies partial_cmp(a, b) == Some(Equal) direction is easy. We have it without adding a special case.
The converse is harder: if s_lo == o_lo && s_hi == o_hi we get Some(Equal), but s_ctxt may not be o_ctxt.

[oli-obk]

Maybe Spans should just be PartialOrd, but not Ord. I'll try if we can get away with just removing Ord

Edit: ah no, we need Ord for sort and friends.

Yea, idk how to solve this in a way that makes everything work out, except go full in with https://github.com/rust-lang/rust/compare/master...oli-obk:rust:no_ord_span?expand=1, no matter how annoying it is

[petrochenkov]

Is it hard to remove PartialOrd from Span and use some explicit location_only_ordering_hygiene_is_ignored method instead?
If the change affects SyntaxContext only, then the cure seems to be worse than the disease.

[oli-obk]

@rustbot author

I'll explore that, but I think at least borrowck uses it to sort its diagnostics

[oli-obk]

Is it hard to remove PartialOrd from Span and use some explicit location_only_ordering_hygiene_is_ignored method instead? If the change affects SyntaxContext only, then the cure seems to be worse than the disease.

I tried it, but sorting spans is used all over the compiler, even if we added convenience helpers for it, the right way would be to replace most of these spans with a SpanSortedByBytePos wrapper struct, everything else is too annoying. See https://github.com/rust-lang/rust/compare/master...oli-obk:rust:no_ord_span?expand=1 for a hacky way towards that

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.