Auto merge of #6931 - Jarcho:needless_borrow, r=phansch,flip1995
Fix all occurences `needless_borrow` internally
The bug that got 'needless_borrow' moved into the nursery was fixed two years ago in d4370f8b.
This did trigger over a thousand times internally, so that's all the other changes. I vetted most of them, but there's a lot The only interesting change is to the lint list. `declare_tool_lint` already makes a reference, so there's no need to take a reference to the lints.
Auto merge of #6463 - xFrednet:5234-shared-code-in-if-blocks, r=phansch
New Lint: `branches_sharing_code`
This lint checks if all `if`-blocks contain some statements that are the same and can be moved out of the blocks to prevent code duplication. Here is an example:
```rust
let _ = if ... {
println!("Start"); // <-- Lint for code duplication
let _a = 99;
println!("End"); // <-- Lint for code duplication
false
} else {
println!("Start");
let _b = 17;
println!("End");
false
};
```
This could be written as:
```rust
println!("Start");
let _ = if ... {
let _a = 99;
false
} else {
let _b = 17;
false
};
println!("End");
```
---
This lint will get masked by the `IF_SAME_THEN_ELSE` lint. I think it makes more sense to only emit one lint per if block. This means that the folloing example:
```rust
if ... {
let _a = 17;
} else {
let _a = 17;
}
```
Will only trigger the `IF_SAME_THEN_ELSE` lint and not the `SHARED_CODE_IN_IF_BLOCKS` lint.
---
closes: #5234
changelog: Added a new lint: `branches_sharing_code`
And hello to the one that is writing the changelog for this release :D
Auto merge of #7026 - daxpedda:cargo-author, r=camsteffen
Remove author requirement for `cargo_common_metadata`
This PR follows https://github.com/rust-lang/cargo/pull/9282, I'm not fully informed about all of this, it would be great if somebody knowledgeable about this topic agrees.
changelog: Changed `cargo_common_metadata` to stop linting on the optional author field.
xFrednet [Fri, 11 Dec 2020 22:29:53 +0000 (22:29 +0000)]
A new lint for shared code in if blocks
* Added expression check for shared_code_in_if_blocks
* Finishing touches for the shared_code_in_if_blocks lint
* Applying PR suggestions
* Update lints yay
* Moved test into subfolder
Auto merge of #7031 - xFrednet:5234-quick-fix-dark-mode-themes, r=llogiq
Quick fix for the updated website theaming to access the correct css files
This fixes a problem from #7030 that the service used to access css files was blocked by GitHub pages due to `SSL_ERROR_BAD_CERT_DOMAIN`. The css file loading worked fine during local development. The browser probably disabled some security options due to the local address.
This fix works locally and should also work online as it references the direct css files used by the [mdBook User Guide](https://rust-lang.github.io/mdBook/index.html) the disadvantage of this is that refactorings within the mdBook project can have effects on the theme loading of Clippy. This PR is therefor more meant as a quick fix until I find a better solution.
I've tested these changes using the page editor in the browser and can now confirm that they work :)
bors [Wed, 31 Mar 2021 21:57:48 +0000 (21:57 +0000)]
Auto merge of #7010 - camsteffen:if-chain-lint, r=llogiq
Internal `if_chain!` lints
changelog: none
We use `if_chain!` a lot. So this enforces some style rules around it, internal only.
Lints when...
* Nested `if`/`if_chain!` can be collapsed
* An `if_chain!` starts with `let` or ends with `let ..; then {..}`
* An `if_chain!` has only one `if`
* An `if_chain!` contains `if .. && ..;` that spans multiple lines
bors [Wed, 31 Mar 2021 18:58:52 +0000 (18:58 +0000)]
Auto merge of #7008 - matthiaskrgr:ltchk, r=camsteffen
lintcheck: warn if we get a bad exit status while running clippy
Right now we won't notice if a crate fails to build.
Print a warning message to indicate that there is a problem of some sort.
I'll still have to do more investigation on why this actually happens.
I suspect that the problem is that `clippy fix` might run --all-targets but when we download the crate source from crates.io, some path deps (used for internal tests etc...) are not available (which is usually not a problem because the internal tests are not needed when using the crate as a lib..?)
bors [Wed, 31 Mar 2021 18:30:32 +0000 (18:30 +0000)]
Auto merge of #6913 - camsteffen:method-chain, r=flip1995
Destructure args in `methods`
changelog: none
This changes the main pattern in `methods` to match and destructure the method call args at the same time as the method name, and pass individual arg `Expr`s to the lint impls.
```rust
// before
["expect", ..] => expect::check(cx, expr, arg_lists[0]);
// after
("expect", [arg]) => expect::check(cx, expr, recv, arg);
```
This makes the code safer since there is no risk of out of bounds `args[n]` everywhere. There will be no more collecting `method_names`, `arg_lists`, `method_spans` as a separate step - everything comes out of the `match`es. Chained methods are parsed in a nested `match`. This makes the code more verbose in some ways, but IMO it is much easier to follow.
~Definitely should wait for #6896. Just putting out the idea.~
bors [Wed, 31 Mar 2021 16:19:07 +0000 (16:19 +0000)]
Auto merge of #6342 - bbqbaron:issue-6061, r=flip1995
Lint: filter(Option::is_some).map(Option::unwrap)
Fixes #6061
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog:
* add new lint for filter(Option::is_some).map(Option::unwrap)
First Rust PR, so I'm sure I've violated some idioms. Happy to change anything.
I'm getting one test failure locally -- a stderr diff for `compile_test`. I'm having a hard time seeing how I could be causing it, so I'm tentatively opening this in the hopes that it's an artifact of my local setup against `rustc`. Hoping it can at least still be reviewed in the meantime.
I'm gathering that since this is a method lint, and `.filter(...).map(...)` is already checked, the means of implementation needs to be a little different, so I didn't exactly follow the setup boilerplate. My way of checking for method calls seems a little too direct (ie, "is the second element of the expression literally the path for `Option::is_some`?"), but it seems like that's how some other lints work, so I went with it. I'm assuming we're not concerned about, eg, closures that just end up equivalent to `Option::is_some` by eta reduction.
My previous fix did not work for enums because enum variants were checked separately in the `check_variant` function but it looks like we can't use that because we can't tell if the enum the variants belong to is declared as public or not (it always said `Inherited` for me)
I went and special-cased enums and iterated over all the variants "manually", but only, if the enums is not public.
---
changelog: fix upper_case_acronyms still firing on public enums (#6803)
bors [Wed, 31 Mar 2021 14:35:48 +0000 (14:35 +0000)]
Auto merge of #6938 - Y-Nak:refactor-types, r=flip1995
Refactor types
r? `@flip1995`
This is the last PR to close #6724 :tada:
Also, this fixes #6936.
changelog: `vec_box`: Fix FN in `const` or `static`
changelog: `linkedlist`: Fix FN in `const` or `static`
changelog: `option_option`: Fix FN in `const` or `static`
bors [Tue, 30 Mar 2021 05:25:28 +0000 (05:25 +0000)]
Auto merge of #7000 - Jarcho:clone_on_copy_fp, r=llogiq
Improve `clone_on_copy`
This also removes the `clone_on_copy_mut` test as the same thing is covered in the `clone_on_copy` test.
changelog: `copy_on_clone` lint on chained method calls taking self by value
changelog: `copy_on_clone` only lint when using the `Clone` trait
changelog: `copy_on_clone` correct suggestion when the cloned value is a macro call.
Jason Newcomb [Mon, 29 Mar 2021 17:29:58 +0000 (13:29 -0400)]
Improve `clone_on_copy`
Lint on `_.clone().method()` when method takes self by value
Set applicability correctly
Correct suggestion when the cloned value is a macro call. e.g. `m!(x).clone()`
Don't lint when not using the `Clone` trait
projects / rust.git / log