clippy fix: remove manual PartialEq::ne #143377

hkBst · 2025-07-03T14:28:49Z

Removes manual impls of PartialEq::ne which are equivalent to the default.

rustbot · 2025-07-03T14:28:55Z

rustbot has assigned @tgross35.
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

taiki-e · 2025-07-03T15:01:03Z

equivalent to the default

Note that implementations for reference types are not strictly the same as the default because they are forwarding of the underlying implementation. In such cases, if the compiler cannot optimize the inversion of the result from the underlying implementation (e.g., inline assembly or FFI is used), then ne may generate an extra 1-2 instructions (xor with constant 1 or set constant 1 to the register and xor with it).

hkBst · 2025-07-03T16:53:43Z

@taiki-e that is a good point, thanks!

tgross35 · 2025-07-03T20:57:42Z

library/core/src/cmp.rs

+        // if <A as PartialEq<B>>::ne uses inline assembly or FFI, then
+        // this forwarding impl may be more efficient than the default impl
+        #[allow(clippy::partialeq_ne_impl)]


Probably allow->expect so we get a bit of noise if these change for some reason.

Maybe just make this a module-level attribute? Since it applies to all but one fn ne in this file.

But at module level would it not also conflict with the few missing ne, at least as expect?

I was thinking of removing duplication a bit with a macro here, since the four cases of (&mut, &mut), (&mut, &), (&, &mut), (&, &) are (nearly?) identical. That would also collapse most of these annotations...

I've now collapsed this with macros to just one PartialEq::ne impl with an expect.

workingjubilee · 2025-07-06T23:29:36Z

I don't think we should add macros to appease the thing that is linting in an effort to make the code more readable.

Adding macros is rather the opposite of making the code more readable.

hkBst · 2025-07-07T06:57:11Z

@workingjubilee macros like these are used all over the library for repeating impls just like here... Do you feel the same way about those, or can you explain why you think these are any different?

workingjubilee · 2025-07-07T21:01:06Z

If you look you will find that I have pushed people to reduce the usage of macros in other PRs, yes.

hkBst · 2025-07-08T12:48:57Z

Very well, I was just trying to clarify your point. Macros come with the disadvantage of more complicated code, but one advantage of using macros like this is that it is easier to see which code is identically duplicated and which parts contain differences. Opinions will vary on in which cases the upside outweighs the downside.

My latest change introduced 3 macros:

The first repeats something for all combinations of two references each of which can be mut or not, so 4 times total. To me this seems justified.
The second repeats a larger impl block 2 times, which also seems justified. It also raises the question of the 2 missing impls, to which I don't know the answer.
The last repeats a simple impl for ordinary and mutable refs, so 2 times. It is also very simple, so also seems justified to me, but I don't feel very strongly about this one.

tgross35 · 2025-07-08T21:17:50Z

I don't have any strong preferences here

r? workingjubilee

rustbot · 2025-07-08T21:17:55Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

bors · 2025-07-13T12:27:18Z

☔ The latest upstream changes (presumably #143867) made this pull request unmergeable. Please resolve the merge conflicts.

fee1-dead · 2025-07-13T14:30:13Z

library/core/src/cmp.rs

-                #[inline]
-                fn ne(&self, other: &Self) -> bool { *self != *other }


Primitive ne isn't equivalent to !(*self == *other). This difference goes straight to MIR and codegen:

rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs

Lines 822 to 833 in 0fb279b

mir::BinOp::Ne

| mir::BinOp::Lt

| mir::BinOp::Gt

| mir::BinOp::Eq

| mir::BinOp::Le

| mir::BinOp::Ge => {

if is_float {

bx.fcmp(base::bin_op_to_fcmp_predicate(op), lhs, rhs)

} else {

bx.icmp(base::bin_op_to_icmp_predicate(op, is_signed), lhs, rhs)

}

}

Yes it can be trivially optimized away but why emit additional IR when you can emit less?

Interesting! I suppose that treatment may be necessary in case these are implemented by inline assembly or via FFI.

Yes it can be trivially optimized away but why emit additional IR when you can emit less?

The documentation in this very file says that:

/// The default implementation of `ne` provides this consistency and is almost /// always sufficient. It should not be overridden without very good reason.

Is the performance impact of emitting slightly more IR really a very good reason? I would expect it is on the edge of immeasurable.

Is the performance impact of emitting slightly more IR really a very good reason? I would expect it is on the edge of immeasurable.

That is a very interesting question since we do in fact have some measurements! Let's at least find out if our existing ones would say anything.

My reservation wasn't mainly about the performance impact. I'm thinking of alternative codegen backends that read Rust MIR and generate code with instruction sets that have ne as well as eq for primitives.

Rather than telling people to rely on MIR opts or LLVM opts (when the backend may not be LLVM) I'd prefer us to do something better on the outset.

The other thing is that it just feels weird? I just don't think clippy is very applicable to this specific case.

And like, what's the benefit here? Of course we don't have to be biased towards the status quo but what is the difference between the change and the status quo?

These are just two lines in a macro. Removing them isn't too much different from keeping them.

The difference would be that the code would then do what the comment about implementing ne seems to recommend. Removing ne is just one of three ways of achieving that, and merely the one that seemed most likely to work at the time. But I'm also happy to document the "very good reason" why we want to impl ne here, or change the comment or both.

bors · 2025-08-07T14:24:24Z

☔ The latest upstream changes (presumably #144997) made this pull request unmergeable. Please resolve the merge conflicts.

workingjubilee · 2025-09-10T04:57:47Z

The question of measurable performance impact if any was raised so we might as well test this much, even if it's not the be-all end-all of performance testing since our runtime benches remain lacking:

@bors try @rust-timer queue

clippy fix: remove manual PartialEq::ne

rust-bors · 2025-09-10T07:02:58Z

☀️ Try build successful (CI)
Build commit: ed44707 (ed4470790af94f2233b1f4e18fa14d11b4c0aafb, parent: 7ad23f43a225546c095123de52cc07d8719f8e2b)

rust-timer · 2025-09-10T08:13:37Z

Finished benchmarking commit (ed44707): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 2.8%, secondary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Cycles

Results (secondary -2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-3.4%, -2.1%]	6
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 469.26s -> 468.084s (-0.25%)
Artifact size: 387.51 MiB -> 387.50 MiB (-0.00%)

bors · 2025-09-12T21:26:49Z

☔ The latest upstream changes (presumably #144847) made this pull request unmergeable. Please resolve the merge conflicts.

workingjubilee · 2025-09-10T22:38:44Z

library/core/src/cmp.rs

-            PartialEq::ne(*self, *other)
-        }
-    }
+    partial_ord_impl!((&A => A, &B => B) /*(&A => A, &mut B => B) (&mut A => A, &B => B)*/ (&mut A => A, &mut B => B));


My primary objection with macros is I find deducing their invented syntax, like this, to often be confounding, unless it is a simple listing of things. I broadly prefer it when the "argument" continues to look like Rust code, and am actually willing to tolerate a more complex macro if it continues looking like Rust code. It also is nice if a span actually consistently points to the trait definition instead of a macro invocation.

The following oversimplified example is valid to do:

trait Something { fn stuff(); fn thingy(); } macro_rules! something_body { () => { fn stuff() { () } fn thingy() { () } } } impl Something for u8 { something_body!(); }

I would somewhat prefer it.

Thanks for these comments. I agree that the current invented syntax is not optimal. I'll see if I can do better.

I changed the syntax to be more rust-like. Let me know if it helps.

@rustbot ready

I just happened across https://github.com/rust-lang/rust/blob/master/library/std/src/path.rs#L3594-L3685 which does things very similarly to my current proposal.

workingjubilee · 2025-09-12T21:29:44Z

@rustbot author

rustbot · 2025-09-17T14:57:44Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned tgross35 Jul 3, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 3, 2025

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from fe36c54 to eac6335 Compare July 3, 2025 17:42

This comment has been minimized.

Sign in to view

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from eac6335 to 4489647 Compare July 3, 2025 18:34

tgross35 reviewed Jul 3, 2025

View reviewed changes

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from 4489647 to 88f2556 Compare July 4, 2025 09:35

rustbot assigned workingjubilee and unassigned tgross35 Jul 8, 2025

rust-cloud-vms bot force-pushed the clippy-fix-5 branch 2 times, most recently from 59bece7 to 3c1c6e9 Compare July 9, 2025 13:01

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from 3c1c6e9 to 9c60f35 Compare July 13, 2025 14:23

fee1-dead reviewed Jul 13, 2025

View reviewed changes

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from 9c60f35 to 187c020 Compare August 24, 2025 15:32

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Sep 10, 2025

Auto merge of #143377 - hkBst:clippy-fix-5, r=<try>

ed44707

clippy fix: remove manual PartialEq::ne

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 10, 2025

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 10, 2025

workingjubilee reviewed Sep 12, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 12, 2025

hkBst added 3 commits September 17, 2025 13:14

clippy fix: remove or annotate manual PartialEq::ne

c247336

reduce repetition with macros

fbc5eeb

make macro syntax more like rust syntax

a31104c

rust-cloud-vms bot force-pushed the clippy-fix-5 branch from 187c020 to a31104c Compare September 17, 2025 14:57

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 17, 2025

		#[inline]
		fn ne(&self, other: &Self) -> bool { self != other }

	mir::BinOp::Ne
	\| mir::BinOp::Lt
	\| mir::BinOp::Gt
	\| mir::BinOp::Eq
	\| mir::BinOp::Le
	\| mir::BinOp::Ge => {
	if is_float {
	bx.fcmp(base::bin_op_to_fcmp_predicate(op), lhs, rhs)
	} else {
	bx.icmp(base::bin_op_to_icmp_predicate(op, is_signed), lhs, rhs)
	}
	}

clippy fix: remove manual PartialEq::ne #143377

Are you sure you want to change the base?

clippy fix: remove manual PartialEq::ne #143377

Uh oh!

Conversation

hkBst commented Jul 3, 2025

Uh oh!

rustbot commented Jul 3, 2025

Uh oh!

taiki-e commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hkBst commented Jul 3, 2025

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee commented Jul 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hkBst commented Jul 7, 2025

Uh oh!

workingjubilee commented Jul 7, 2025

Uh oh!

hkBst commented Jul 8, 2025

Uh oh!

tgross35 commented Jul 8, 2025

Uh oh!

rustbot commented Jul 8, 2025

Uh oh!

bors commented Jul 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Aug 7, 2025

Uh oh!

This comment has been minimized.

workingjubilee commented Sep 10, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Sep 10, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Sep 10, 2025

Overall result: no relevant changes - no action needed

Uh oh!

bors commented Sep 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee commented Sep 12, 2025

Uh oh!

rustbot commented Sep 17, 2025

Uh oh!

Uh oh!

taiki-e commented Jul 3, 2025 •

edited

Loading

workingjubilee commented Jul 6, 2025 •

edited

Loading