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.

[cjgillot]

@bors r+ rollup=never

[bors]

📌 Commit 4239a73 has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4239a73 with merge 25c9f2c...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 25c9f2c to master...

[rust-timer]

Finished benchmarking commit (25c9f2c): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.3%, 0.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	1

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary -2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 694.36s -> 694.089s (-0.04%)
Artifact size: 326.84 MiB -> 326.85 MiB (0.00%)