The <*const T>::guaranteed_* methods now return an option for the unknown case

[oli-obk]

cc #53020 (comment)

I chose 0 for "not equal" and 1 for "equal" and left 2 for the unknown case so backends can just forward to raw pointer equality and it works ✨

r? @fee1-dead or @lcnr

cc @rust-lang/wg-const-eval

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[fee1-dead]

LGTM. r= me if nothing else happens

[oli-obk]

I have decided to remove guaranteed_ne, there is no advantage to having it around anymore (as the result is now the same as eq, but with the boolean inverted).

[RalfJung]

Given that we have PartialEq::eq and ne, IMO it makes sense to also have both here for CTFE ptr comparison.

[oli-obk]

Given that we have PartialEq::eq and ne, IMO it makes sense to also have both here for CTFE ptr comparison.

I don't believe so. The reason we created ne was due to the inconsistency between equality and inequality. That is gone now. We could rename it to guaranteed_same or sth, but considering you already need to match on the option, there's little gain in having a convenience ne operation. In fact I would say it creates more confusion than it aids.

[RalfJung]

The reason we created ne was due to the inconsistency between equality and inequality.

I don't agree. We have PartialEq::ne and the != operator despite there being no inconsistency.

[oli-obk]

The reason we created ne was due to the inconsistency between equality and inequality.

I don't agree. We have PartialEq::ne and the != operator despite there being no inconsistency.

These operators are inverses of each other and return a bool. Here, they return an Option<bool>, which seems sufficiently different from the other equality ops to me. Anyway, I don't feel strongly about it, just noticed it while updating the docs which were talking about the fact that the functions aren't inverses of each other, but ignoring the None case they are now. There's no information gain from having both functions. I expect most usages will be foo.guaranteed_eq(bar) == Some(true) or == Some(false) instead of extracting the bool.

[fee1-dead]

@bors r+

[bors]

📌 Commit f632dbe has been approved by fee1-dead

It is now in the queue for this repository.

[bors]

⌛ Testing commit f632dbe with merge 5197c96...

[bors]

☀️ Test successful - checks-actions
Approved by: fee1-dead
Pushing 5197c96 to master...

[rust-highfive]

📣 Toolstate changed by #101483!

Tested on commit 5197c96.
Direct link to PR: #101483

💔 miri on windows: test-pass → test-fail (cc @RalfJung @oli-obk).
💔 miri on linux: test-pass → test-fail (cc @RalfJung @oli-obk).

[rust-timer]

Finished benchmarking commit (5197c96): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

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

	mean1	range	count2
Regressions ❌ (primary)	0.4%	[0.2%, 0.6%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.1%	[-1.4%, -0.9%]	5
Improvements ✅ (secondary)	-2.9%	[-3.8%, -0.7%]	8
All ❌✅ (primary)	-0.4%	[-1.4%, 0.6%]	10

Max RSS (memory usage)

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	5.1%	[2.3%, 8.8%]	6
Regressions ❌ (secondary)	0.9%	[0.6%, 1.1%]	3
Improvements ✅ (primary)	-4.1%	[-4.1%, -4.1%]	1
Improvements ✅ (secondary)	-1.5%	[-2.3%, -1.0%]	6
All ❌✅ (primary)	3.8%	[-4.1%, 8.8%]	7

Cycles

Results

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.

	mean1	range	count2
Regressions ❌ (primary)	3.0%	[3.0%, 3.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.8%, -2.0%]	7
All ❌✅ (primary)	3.0%	[3.0%, 3.0%]	1

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[pnkfelix]

The big improvements are just noise from some bimodal behavior we've been observing this week.

Its possible that there was some regression to cargo here, but I don't think the data shows it to be large enough to be worth investigating. (I admit, my attitude there might be colored by my frustration with the huge noise impact of the aforementioned bimodality on all of the perf results from the last week.)

@rustbot label: perf-regression-triaged