Suggest `Option<&T>` instead of `&Option<T>`
closes#13054
```rust
// bad code
fn foo(a: &Option<T>) {}
fn bar(&self) -> &Option<T> {}
// Use instead
fn foo(a: Option<&T>) {}
fn bar(&self) -> Option<&T> {}
```
Handles argument types and return types in functions, methods, and closures with explicit types. Honors `avoid_breaking_exported_api` parameter.
See this great [YouTube video](https://www.youtube.com/watch?v=6c7pZYP_iIE) with the in-depth explanation.
### Open Questions
These are not blocking, and could be done in separate PRs if needed.
* [ ] Should `&Option<Box<T>>` be suggested as `Option<&T>` -- without the box? Handled by [clippy::borrowed_box](https://rust-lang.github.io/rust-clippy/master/index.html#/borrowed_box)
* [ ] Should `&Option<String>` be suggested as `Option<&str>` -- using de-refed type?
### Possible Future Improvements
These cases might also be good to handle, probably in a separate PR.
```rust
fn lambdas() {
let x = |a: &Option<String>| {};
let x = |a: &Option<String>| -> &Option<String> { todo!() };
}
fn mut_ref_to_ref(a: &mut &Option<u8>) {}
```
changelog: [`ref_option`]: Suggest `Option<&T>` instead of `&Option<T>`
Remove method call receiver special casing in `unused_async` lint
Fixes the false positive mentioned in https://github.com/rust-lang/rust-clippy/issues/13466#issuecomment-2380025514.
The false negative in the OP would be nice to fix too, but I'd rather do that in a separate PR because it's much more involved
Before this change, the `unused_async` lint would check if the async fn is also used anywhere and avoid linting if so. The exception is if the async function is immediately called, because the returned future handling can be easily removed (and also if we don't have some exceptions then the lint wouldn't trigger anywhere) *or* if it's a method call receiver.
I'm not exactly sure why I implemented that special casing for method call receivers in #11200, but it doesn't make much sense in hindsight imo. Especially given that method calls are essentially equivalent to function calls with the receiver as the first argument, which was the primary motivation for not linting in the first place (async fn passed to another function, like `axum::get(handler)` where handler has to be an async fn).
changelog: none
fix(clippy_lints/matches): wildcard_in_or_patterns will no longer be triggered for types annotated with #[nonexhaustive]
fixes#13350
----
changelog: none
Use std_or_core to determine the correct prefix
This is a cleanup commit. It replaces hand-crafted tests by the a call to the `std_or_core()` utility function.
changelog: none
Lint comparison to empty slice using `PartialEq` methods
changelog: [`comparison_to_empty`]: Also detect comparaisons using `PartialEq` methods
Fix#13401
Split def_path_res into two parts
`def_path_res` previously had two jobs:
1. looking up the crates to find the path in
2. looking up path in said crates
This splits that job up into two functions, keeping `def_path_res` as an adapter between the both, to avoid repeating the first step when repeatedly looking up items in the same crate.
changelog: none
Use contiguous spans for empty_line_after_* suggestion
Replacing an empty span (which an empty line is) with an empty string triggers a debug assertion in rustc. This fixes the debug assertion by using contiguous spans, with the same resulting suggestion.
r? `@Alexendoo`
This unblocks the sync
changelog: none
Check that #[deny(allow_attributes)] do not issue spurious messages
Add a new test for #13380. This bug was caused by a bug in rustc which has been fixed in 6ee87ae594.
Close#13380
changelog: [`allow_attributes`]: fix spurious warning messages
Replacing an empty span (which an empty line is) with an empty string triggers a
debug assertion in rustc. This fixes the debug assertion by using contiguous
spans, with the same resulting suggestion.
Build quine-mc_cluskey with `opt-level=3` in dev builds
While doing some profiling I noticed that debug clippy running on the `clippy_lints` crate spends 35s out of 160s in one specific code path of `nonminimal_bool`, which seemed a bit excessive.
I've found that just enabling optimizations for quine-mc_cluskey (used by nonminimal_bool) cuts down the part that took 35s to 3s
While this doesn't really change anything for users, this helps dogfood a bit as it cuts off about half a minute of runtime (in some of my tests, at least).
Something similar was attempted in #10576, however that involved compiling everything in release mode including clippy itself, whereas this only affects a single dependency that's compiled in parallel with something that takes longer so this should hopefully not have a negative impact in any case (and changing clippy doesn't require recompiling that dependency)
changelog: none
Unused trait imports (formerly anonymous trait import)
For #11969
I'm looking for help and feedback on implementing a new lint for suggesting `use ... as _` for traits where possible.
I have had a go at implementing this but I don't know if this is the best way to do it as I am new to clippy.
There are some edge cases I can think of where this doesn't work but have aired on the side of false negatives instead of false positives.
An example of a false negative. I couldn't figure out the best way to resolve an import from within clippy. The sub module imports MyAny so that cannot be anonymized but `use std::any::Any` could be. In this case it is not caught because `Any` and `MyAny` have the same DefId.
```rust
mod nested_mod_used_bad1 {
use std::any::Any;
use std::any::Any as MyAny;
mod foo {
use crate::nested_mod_used_bad1::MyAny;
fn foo() {
println!("{:?}", MyAny::type_id("foo"));
}
}
}
```
Any feedback is much appreciated.
-------
changelog: new lint: `unused_trait_names`
Fix `if_then_some_else_none` sugg missing closure intro
Fixes#13407#13407 works in current stable. The suggestion-generating code got trampled over in 0532104247 :-)
changelog: [`if_then_some_else_none`]: Fix missing closure in suggestion
Initial impl of `unnecessary_first_then_check`
Fixes#11212
Checks for `{slice/vec/Box<[]>}.first().is_some()` and suggests replacing the unnecessary `Option`-construct with a direct `{slice/...}.is_empty()`. Other lints guide constructs like `if let Some(_) = v.get(0)` into this, which end up as `!v.is_empty()`.
changelog: [`unnecessary_first_then_check`]: Initial implementation
