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.
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
[`missing_panics_doc`] Fix#13381Fix#13381
Makes `missing_panics_doc` act like other "panicking" lints (`unwrap_used`, `panic`, etc) in constant environments.
changelog: Ignore `missing_panics_doc` in constant environments
Look at adjusted types instead of fn signature types in `ptr_arg`
This simplifies the implementation of the `ptr_arg` lint a bit and:
Fixes#13308Fixes#10612
Currently, the lint checks if e.g. a `&String` parameter is only used in contexts where a `&str` could work. Part of it worked by looking for path exprs to that parameter in function call position specifically, looking at the callee signature and checking if that parameter type without refs is `String` (or one of a bunch of other special cases).
This simplified version removes the special casing of function calls and looking at the parameter type and instead just looks at the **adjusted type**, regardless of the expression it's in. This naturally also covers what the previous version was doing (if the expression is in a function call argument position expecting a `&str`, then it will have that adjustment. If it requires a `&String` then it won't have that adjustment and we won't lint).
The linked issue was a FP that happened because the previous implementation simply didn't consider projection types in the signature type, but with this simplification we don't really need to consider that (because we aren't looking at function signatures at all anymore -- the `&mut Self::Owned` parameter type of `clone_into` is the already-instantiated and normalized type `&mut String`).
changelog: none
