Make manual_is_variant_and to cover manual is_none_or

[profetia]

Closes #16419

changelog: [manual_is_variant_and] enhance to cover manual is_none_or

[rustbot]

r? @Jarcho

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

[Jarcho]

This needs an MSRV check. is_none_or is from 1.82 whereas is_some_and is from 1.70. You should also be checking for is_some_and || is_none as well.

View changes since this review

[profetia]

All resolved. Thank you!

[Jarcho]

You can remove some redundant work by using something like:

let (none_recv, some_recv, some_arg) = match (&lhs.kind, &rhs.kind) {
  (
    ExprKind::MethodCall(sym::is_none, none_recv, [], ..),
    ExprKind::MethodCall(sym::is_some, some_recv, [some_arg], ..),
  ) => (none_recv, some_recv, some_arg),
  (
    ExprKind::MethodCall(sym::is_some, some_recv, [some_arg], ..),
    ExprKind::MethodCall(sym::is_none, none_recv, [], ..),
  ) => (none_recv, some_recv, some_arg),
  _ => return,
};

---

You also don't want to use method_call since it doesn't allow any of the arguments to be from an expansion. It really shouldn't ever be used.

View changes since this review

[ada4a]

This looks very awkward imo. Since this particular pattern (opt.is_none() || opt.is_some_and()) doesn't really fit into the methods group, maybe it would make sense to create a separate top-level file to put it into? What do you all think?

[profetia]

I prefer to keep it here.

[Jarcho]

When the lint crate is split either the whole lint will have to be in the methods pass or in a different pass. So this can stay as it is.

[Jarcho]

Thank you.

View changes since this review