Use `check_proc_macro` for `missing_const_for_fn`
This uses `@Jarcho's` #8694 implementation to fix `missing_const_for_fn` linting in proc-macros.
I'm not 100% sure what I'm doing here, any feedback is appreciated.
Previously: https://github.com/Jarcho/rust-clippy/pull/1.
Fixes#8854.
changelog: [`missing_const_for_fn`]: No longer lints in proc-macros
Add partialeq_to_none lint
Initial implementation of #9275, adding lint `partialeq_to_none`. This is my first time working on `clippy`, so please review carefully.
I'm unsure especially about the `Sugg`, as it covers the entire `BinOp`, instead of just covering one of the sides and the operator (see the multi-line example). I was unsure if pinpointing the suggestion wouldn't be brittle...
changelog: [`PARTIALEQ_TO_NONE`]: Initial commit
`explicit_auto_deref` changes
fixes#9123fixes#9109fixes#9143fixes#9101
This avoid suggesting code which hits a rustc bug. Basically `&{x}` won't use auto-deref if the target type is `Sized`.
changelog: Don't suggest using auto deref for block expressions when the target type is `Sized`
changelog: Include the borrow in the suggestion for `explicit_auto_deref`
changelog: Don't lint `explicit_auto_deref` on `dyn Trait` return
changelog: Don't lint `explicit_auto_deref` when other adjustments are required
changelog: Lint `explicit_auto_deref` in implicit return positions for closures
More proc-macro detection
fixes#6514fixes#8683fixes#6858fixes#6594
This is a more general way of checking if an expression comes from a macro and could be trivially applied to other lints. Ideally this would be fixed in rustc's proc-macro api, but I don't see that happening any time soon.
changelog: FPs: [`unit_arg`] [`default_trait_access`] [`missing_docs_in_private_items`]: No longer trigger in code generated from proc-macros.
Move `significant_drop_in_scrutinee` into `nursey`
The current suggestion of extending the lifetime of every sub-expression is not great and doesn't fix the error given in the lint's example, though it does make the potential deadlock easier to see, but it can also cause it's own issues by delaying the drop of the lock guard.
e.g.
```rust
match x.lock().foo {
..
}
// some stuff
let y = x.lock();
```
The suggestion would create a deadlock at the second `x.lock()` call.
This also lints even when a significant drop type isn't created as a temporary. (#9072)
I agree `@kpreid` (https://github.com/rust-lang/rust-clippy/issues/8987#issuecomment-1207464440) that this should be back-ported before the lint hits stable.
changelog: Move `significant_drop_in_scrutinee` into `nursey`
