fix equatable_if_let: don't suggest = in const context
#15482
Conversation
rustbot
added
the
S-waiting-on-review
ada4a
force-pushed
the
equatable-if-in-consts
branch
from
4b19a31 to
96838e2
Compare
ada4a
changed the title
equatable_if_let: FP in const contextequatable_if_let: don't suggest = in const context
tests/ui/equatable_if_let.rs
Outdated
| //~^ ERROR: this pattern matching can be expressed using `matches!` | ||
|
|
||
| // FIXME:suggests `==` | ||
| //const _: u32 = if let Some(NonConstEq) = None { 0 } else { 1 }; |
There was a problem hiding this comment.
why on earth does this happen
There was a problem hiding this comment.
is_stable_const_fn doesn't handle this case at all.
There was a problem hiding this comment.
Do you know of a way to make it to?..
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I don't completely get that code if I'm being honest. If I understand correctly, it checks that:
- the given trait:
- defines one and only function
- and that function is
const
- the given type has at least one (non-blanket) impl of that trait
- if there are multiple such impls, checks that the implementation of the one and only function is
constas 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.
ada4a
force-pushed
the
equatable-if-in-consts
branch
from
43721b0 to
d5a3511
Compare
ada4a
force-pushed
the
equatable-if-in-consts
branch
from
d5a3511 to
194bcde
Compare
turns out `is_in_const_context` wasn't even supposed to be put in the main let-chain, since it's only relevant for the `is_structural_partial_eq` case Co-authored-by: yanglsh <[email protected]>
we've created it already, so might as well..
before this, the lint would suggest `==` even for types that aren't `const PartialEq` still doesn't work on nested types for some reason
ada4a
force-pushed
the
equatable-if-in-consts
branch
from
194bcde to
283f89d
Compare
fixes #15376
changelog: [
equatable_if_let]: don't suggest=in const context