clippy fix: remove manual PartialEq::ne

[hkBst]

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

[rustbot]

r? @tgross35

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]

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]

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

[tgross35]

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.

[hkBst]

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...

[hkBst]

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

[workingjubilee]

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]

@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]

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

[hkBst]

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]

I don't have any strong preferences here

r? workingjubilee

[rustbot]

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

[bors]

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

[fee1-dead]

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?

[hkBst]

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.