Fix automatic suggestion on `use_self`.
In an example like this:
```rust
impl Example {
fn fun_1() { }
fn fun_2() {
Example::fun_1();
}
}
```
Clippy tries to replace `Example::fun_1` with `Self`, loosing `::fun_1` in the process, it should rather try to replace `Example` with `Self`.
**Question**
- There may be other paths that need the same treatment, but I'm not sure I understand them fully:
- e648adf086/clippy_lints/src/use_self.rs (L94-L96)
- e648adf086/clippy_lints/src/use_self.rs (L225-L229)
Fix `implicit_return` false positives.
Fixes the following false positives:
- linting on `if let` without `else` in a `loop` even with a present `return`
- linting on `unreachable!()`
Catch up with `format_args` change
Catches up with a change in rust-lang/rust#57537. (Since the optimization is optional, this clippy PR can be merged before the rustc PR.)
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
```
warning: use of `expect` followed by a function call
--> src/main.rs:2:17
|
2 | Some("foo").expect(format!("{} {}", 1, 2).as_ref());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `unwrap_or_else(|| panic!("{} {}", 1))`
|
```
Catches up with a change in rust-lang/rust#57537
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
`cloned` requires that the elements of the iterator must be references. This
change determines if that is the case by examining the type of the closure
argument and suggesting `.cloned` only if it is a reference. When the closure
argument is not a reference, it suggests removing the `map` call instead.
A minor problem with this change is that the new check sometimes overlaps
with the `clone_on_copy` lint.
Fixes#498
Restrict `use_self` on nested items
Fixes#3637Fixes#3463
These changes make it so that nested items aren't visited any more by the `use_self` lint.
I think visiting nested items should be possible (so that it uses a different `item_path` for the nested item), but I'm not sure whether it's viable and what the best approach would be.
- Can `item_path` be changed to a new `Self` path before visiting the item, and then changing it back afterwards?
- Alternatively, could a new visitor be created, re-using `check_trait_method_impl_decl`?
Revert the random_state lint.
Remove the random_state lint until it or rustc has been fixed to no longer crash with debug assertions (see #3628)
We can't update clippy in the rustc repo because of this which is blocking nightlies because toolstate is already broken.
fixes#3628
Add run-rustfix where it already works
This PR adds `// run-rustfix` headers to tests for `MachineApplicable` lints where
applying the suggestions works without any errors.
Trigger `use_self` lint in local macros
Closes#2098
The test currently only covers local macros. #2098 suggested this:
> You could add the macro in question into the `mini_macro` subcrate
But that doesn't work for a `macro_rules`:
```
error: cannot export macro_rules! macros from a `proc-macro` crate type currently
```
So I suggest leaving out the test for external macros, as using `in_external_macro` seems straigtforward enough. Alternatives would be to use to add an additional crate (overkill if you ask me), or test with a `proc-macro`.
UI test cleanup: Extract lint from methods.rs test
Extracts the `result_map_unwrap_or_else` lint into a separate test file.
This also extracts the `IteratorFalsePositives` struct and impl into
`auxiliary/option_helpers.rs`.
cc #2038
Integrate rustfix into Clippy test suite
Once the [PR to compiletest-rs](https://github.com/laumann/compiletest-rs/pull/151) is reviewed and merged this fixes#2376.
I will create a separate tracking issue for adding `run-rustfix` to all tests.
Only trigger `infinite_iter` lint for infinitely allocating `collect()` calls
Fixes #3538
~Oh, I guess this should actually check other methods like `count` as well, not only `collect()`.~
Never mind, `collect` is the only of these functions that allocates a data structure.
Fix if_same_then_else false positive
This fixes false positive in #3559.
The problem was that `SpanlessEq` does not check patterns in declarations. So this two blocks considered equal.
```rust
if true {
let (x, y) = foo();
} else {
let (y, x) = foo();
}
```
Not sure if the proposed change is safe as `SpanlessEq` is used extensively in other lints, but I tried hard to come up with counterexample and failed.
Merge new_without_default_derive into new_without_default
Closes#3525, deprecating new_without_default_derive and moving both lints into new_without_default.
