Auto merge of #7064 - ThibsG:WrongSelfFix, r=giraffate
Fix FP in `wrong_self_convention` lint
Previously, this lint didn't check into impl block when it was implementing a trait.
Recent improvements (#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in #7032.
Fixes #7032
changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint
Auto merge of #7065 - rail-rain:warn_copy_pass_by_ref, r=Manishearth
Add a note on the issue #5953
Hello,
I thought it would be better to have a note and warning about this issue considering it introduced an UB in the past even with the "Search on Github" feature.
---
changelog: Add a note on the issue #5953 to the known problems section.
Auto merge of #7060 - daxpedda:debug-assert-panic-in-result-fn, r=flip1995
Remove `debug_assert` from `panic_in_result_fn`
I couldn't find any documentation on `debug_assert` that should be remove.
In my humble opinion, I would also like to argue that `todo` and `unreachable` shouldn't trigger this lint?
Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov
Use AnonConst for asm! constants
This replaces the old system which used explicit promotion. See #83169 for more background.
The syntax for `const` operands is still the same as before: `const <expr>`.
Fixes #83169
Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
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 :)
The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.
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.
projects / rust.git / log