cc @samueltardieu @Manishearth

My guess is that #14339 introduced this change, which is titled "lint more cases" but the ticket it closed seems to be a bug rather than a proposal to make this lint different. The PR also didn't update the motivation for "why is this bad" at all.

In particular this expansion of the lint is going to hit code using raw pointers quite hard, e.g. we noticed this in pyo3-ffi.

Maybe this change of behaviour to more aggressively forbid == on pointers really is intended. The motivation for it and the churn it may cause when this hits stable doesn't seem justified from what I can see in those discussions.

For what it's worth, I'd argue against this change of behaviour. In my opinion a == b is cleaner than special casing eq(a, b) if a and b are already pointers. Why add the cognitive overhead of a special case?

(On the other hand, I can completely support the lint as it currently functions on stable to make comparison of references by pointer much clearer.)

I think the change was intentional: there's a couple footguns in this area, and potentially more with provenance, so encouraging this style overall seems good.

That said, perhaps we can make it not lint for simple cases where there is no casting and the types are both raw? @samueltardieu , what do you think

cc @rust-lang/clippy on whether we should back this out, do a fix, or leave as is

See https://github.com/PyO3/pyo3/pull/5032/files for what the difference looks like. Personally I find it a bit too churn-y.

I think the change was intentional: there's a couple footguns in this area, and potentially more with provenance, so encouraging this style overall seems good.

That said, perhaps we can make it not lint for simple cases where there is no casting and the types are both raw? @samueltardieu , what do you think

cc @rust-lang/clippy on whether we should back this out, do a fix, or leave as is

I'll do some experiments to see how less linting would look like.

See https://github.com/PyO3/pyo3/pull/5032/files for what the difference looks like. Personally I find it a bit too churn-y.

Generally we're careful about churning, but churn in and of itself isn't bad, especially with cargo clippy --fix. The question is more about whether this change is positive when compared to the amount of churn. I think it comes out mostly even from my view: the clarity in unsafe code is basically always good. But still, perhaps it doesn't actually help much here.

I don't find the churning bad either, but I also understand the rationale of wanting to compare two raw pointers with ==. I have proposed a change for discussion in #14526. As stated by @Manishearth it would be great to have other people's input as well.

I agree with only linting if we can remove a cast

If we should change something with this lint, please label the PR with beta-nominates, so that the current state doesn't hit stable.

To add a counter-argument, in the PyO3 thread it was pointed out to me that using ptr::eq does have the upside of making it very clear that the operation is using pointer equality, not value equality.

I could accept that motivation for preferring ptr::eq. if that is decided as preferred I think it would be worth updating the lint documentation to suggest that.