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
On implicit `Sized` bound on fn argument, point at type instead of pattern
Instead of
```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
--> $DIR/issue-59324.rs:23:20
|
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
| ^^^^^^^ doesn't have a size known at compile-time
```
output
```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
--> $DIR/issue-59324.rs:23:29
|
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
| ^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
```
Instead of
```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
--> $DIR/issue-59324.rs:23:20
|
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
| ^^^^^^^ doesn't have a size known at compile-time
```
output
```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
--> $DIR/issue-59324.rs:23:29
|
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
| ^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
```
fix(clippy_lints/matches): wildcard_in_or_patterns will no longer be triggered for types annotated with #[nonexhaustive]
fixes#13350
----
changelog: none
Clippy subtree update
r? `@Manishearth`
Really delayed sync (2 1/2 weeks), because of a `debug_assertion` we hit, and I didn't have the time to investigate earlier.
It would be nice to merge this PR with some priority, as it includes a lot of formatting changes due to the rustfmt bump.
Include Cargo.lock update due to Clippy version bump and ui_test bump in Clippy.
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
Separate collection of crate-local inherent impls from error tracking
#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until #121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.
Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in #127798.
This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.
This fixes#127798.
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
