why on earth does this happen

is_stable_const_fn doesn't handle this case at all.

Do you know of a way to make it to?..

I'm guessing this part:

cx.tcx
    .trait_of_assoc(def_id)
    .and_then(|trait_def_id| cx.tcx.lookup_const_stability(trait_def_id))

Needs to be changed to getting the container and not the trait.

I haven't followed this discussion closely, but it might be something similar to what I had to do in 86beecc. Maybe this could get factored into a utility function taking both the trait id and the concrete type.

I don't completely get that code if I'm being honest. If I understand correctly, it checks that:

1. the given trait:
   1. defines one and only function
   2. and that function is const
2. the given type has at least one (non-blanket) impl of that trait
3. if there are multiple such impls, checks that the implementation of the one and only function is const as well

(1.i) is fine for assign_op_patterns, since the traits checked there only ever define one function. And it should be okay for PartialEq as well, since eq is its first method. But I think that is a potential footgun worth mentioning in the docs of this function if we do move it to clippy_utils

But am I understanding correctly that (3) is a bit too strict? After all, only the impl that applies to the given situation should have its constness considered -- but it's probably unrealistic to try and find out which impl that is, from inside Clippy. If my understanding is correct, I'd add this as a comment to the function.

@samueltardieu WDYT?

If the function were to be moved to clippy_utils, it would probably need to take the method name as well. As you noted, in the current case there is no need to do so, and we could even have used [0] here to get the only method.

And yes, 3 is stricter than necessary, but finding the right implementation to use in the general case would probably be difficult. The risk with the current solution is a false negative for the lint, which in the current case is not critical.