This has been unstable since it was first introduced in
https://github.com/rust-lang/rust-clippy/pull/5363. In that time, I have
been using it successfully in nightly without issues. I don't think
there are any blocking issues now that RUSTC_WORKSPACE_WRAPPER is
stabilized, so this can be stabilized.
Add suspicious group
changelog: Introduce `clippy::suspicious` 🤔 group and move several lints into the group
Closes#6366. CC #6626.
A number of lints are moved from each of `correctness`, `style` and `complexity` groups. Notably I didn't move `suspicious_splitn` since I think that is a `correctness` lint despite the name.
Lints moved to `clippy::suspicious`:
* `blanket_clippy_restriction_lints` (was `clippy::style`)
* `empty_loop` (was `clippy::style`)
* `eval_order_dependence` (was `clippy::complexity`)
* `float_equality_without_abs` (was `clippy::correctness`)
* `for_loops_over_fallibles` (was `clippy::correctness`)
* `misrefactored_assign_op` (was `clippy::complexity`)
* `mut_range_bound` (was `clippy::complexity`)
* `mutable_key_type` (was `clippy::correctness`)
* `suspicious_arithmetic_impl` (was `clippy::correctness`)
* `suspicious_assignment_formatting` (was `clippy::style`)
* `suspicious_else_formatting` (was `clippy::style`)
* `suspicious_map` (was `clippy::complexity`)
* `suspicious_op_assign_impl` (was `clippy::correctness`)
* `suspicious_unary_op_formatting` (was `clippy::style`)
Do not spawn blacklisted_name lint in test context
---
fixed#7305
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: `blacklisted_name` lint is not spawned in the test context anymore.
Fix detecting of the 'test' attribute
Update UI test to actually check that warning is not triggered in the test code
Fix approach for detecting the test module
Add nested test case
Remove code duplication by extracting 'is_test_module_or_function' into 'clippy_utils'
Cleanup the code
Added `cargo dev setup git-hook` and updated `cargo dev setup intellij` including a `remove` command
This PR enables our dev tool to install a git hook that formats the code before each commit and also runs `update_lints` to make sure that everything is registered correctly. The script is located at `util/etc/pre-commit.sh`. I found it reasonable to locate it in the `util` folder and decided to add a `etc` in correlation to the main rust repo and to bring a bit of structure into it.
* The hook can be installed via: `cargo dev setup git-hook`
* And removed via: `cargo dev remove git-hook`
cc: #5394
The refactoring of `src/ide_setup.rs` to `src/setup/intellij.rs` is an extra commit to simplify the review.
---
Changes:
* Added `cargo dev setup git-hook` for formatting before every commit
* Added `cargo dev remove git-hook` to remove the hook again
* Added `cargo dev remove intellij` to remove rustc source path dependencies
* Changed `cargo dev ide_setup` to `cargo dev setup intellij`
changelog: none
This is only an internal change and therefore not worth an entry in the general change log.
---
Tested on:
* [x] Linux (by `@xFrednet)`
* [ ] Windows (All used commands run inside the git bash, so it's very likely to work as well `@xFrednet)`
* [ ] macOS
Add import_rename lint, this adds a field on the Conf struct
fixes#7276
changelog: Add ``[`import_rename`]`` a lint that enforces import renaming defined in the config file.
Fix invocation of `zst_offset` lint
The `zst_offset` lint was broken by a refactoring regression in 21083875d2. In the invocation of the `zst_offset` check [here](21083875d2 (diff-7f73f6fe28c04b654223c09c42fe02937d2351fc58a91d21ab812aaf6f9b185dR1927)), we shadow the already-destructured receiver `recv`, and accidentally pass the first argument of the method as if it were the receiver.
This was not caught because the UI test expectation was never correct (a bad cast obscured the actual test result).
This PR:
- Fixes the existing test expectation
- Tests both `const` and `mut` raw pointers
- Passes the actual receiver to the lint's implementation
Fixes#7395.
changelog: Fix [`zst_offset`] invocation and test
Fixed broken deploy script due to multiline configuration docs
The deploy script on master currently runs into an error (See [log](https://github.com/rust-lang/rust-clippy/runs/2865828873)) due to the new configuration documentation added in #7299. The current documentation collection for the configuration macro sadly doesn't support multiline doc comments. This will be changes in the future with the new metadata collector tracked in #7172 For now we have to use `<br>` inside doc comments to add paragraphs.
This PR restricts `define_Conf!` macro to single lines and adds a comment explaining the reasoning behind it. It also adjusted the actual document parsing to fix a bug. (The parsing was automatically stopping on the first curly bracket, even if it was part of a doc comment).
changelog: none
Fix wrong config option being suggested for deprecated wrong_pub_self_convention lint
Problem:
for code like
````rust
#![warn(clippy::wrong_pub_self_convention)]
fn main() {
println!("Hello, world!");
}
````
clippy will issue a warning to use a clippy.toml option instead:
````
warning: lint `clippy::wrong_pub_self_convention` has been removed: set the `avoid_breaking_exported_api` config option to `false` to enable the `wrong_self_convention` lint for public items
--> src/main.rs:2:9
|
2 | #![warn(clippy::wrong_pub_self_convention)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
````
But using the lint name as seen in the warning message
`echo "avoid_breaking_exported_api = true\n" > clippy.toml`
Will cause an error:
````
error: error reading Clippy's configuration file `/tmp/clippytest/clippy.toml`: unknown field `avoid_breaking_exported_api`, expected one of `avoid-breaking-exported-api`, ...
````
Replace the underscores with dashes in the deprecation message.
changelog: avoid_breaking_exported_api: suggest correct clippy config toml option in the deprecation message
Improve panic message on "Found multiple rlibs" error in compile-test
Related to #7343
When I first met this error I was pretty much confused, so I thought it may be a good idea to:
- Give a hint on what to do to users that don't want to dig into specifics and just want to quickly resolve the issue.
- Give a link for those who are interested in details.
## Old appearance:
<img width="1121" alt="Screenshot 2021-06-20 at 08 30 34" src="https://user-images.githubusercontent.com/12111581/122663361-df8ae780-d1aa-11eb-9236-775b4fd754d5.png">
## New appearance:
<img width="1121" alt="Screenshot 2021-06-20 at 08 32 18" src="https://user-images.githubusercontent.com/12111581/122663363-e4e83200-d1aa-11eb-9c46-f62d83eb79e2.png">
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
Replace some `std::iter::repeat` with `str::repeat`
I noticed that there were some instances where `std::iter::repeat` would be used to repeat a string or a char to take a specific count of it and then collect it into a `String` when `str::repeat` is actually much faster and better for that.
See also: https://github.com/rust-lang/rust-clippy/issues/7260.
Problem:
for code like
````
fn main() {
println!("Hello, world!");
}
````
clippy will issue a warning to use a clippy.toml option instead:
````
warning: lint `clippy::wrong_pub_self_convention` has been removed: set the `avoid_breaking_exported_api` config option to `false` to enable the `wrong_self_convention` lint for public items
--> src/main.rs:2:9
|
2 | #![warn(clippy::wrong_pub_self_convention)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
````
But using the lint name as seen in the warning message
echo "avoid_breaking_exported_api = true\n" > clippy.toml
Will cause an error:
````
error: error reading Clippy's configuration file `/tmp/clippytest/clippy.toml`: unknown field `avoid_breaking_exported_api`, expected one of `avoid-breaking-exported-api`, ...
````
Replace the underscores with dashes in the deprecation message.
changelog: avoid_breaking_exported_api: suggest correct clippy config toml option in the deprecation message
Add macro_braces lint to check for irregular brace use in certain macros
The name is a bit long but this sounds good as `#[allow(unconventional_macro_braces)]` and it seems more clear that we are talking about the macro call not macro definitions, any feedback let me know. Thanks!
fixes#7278
changelog: Add ``[`unconventional_macro_braces`]`` lint that checks for uncommon brace usage with macros.
Move from-iter-instead-of-collect to pedantic
Since FromIterator will become part of the prelude, this lint being
warn by default is incongruous with the libs team position on the topic.
Fixes#7213.
---
changelog: moved [`from_iter_instead_of_collect`] to `pedantic` group
Remove some last remants of {push,pop}_unsafe!
These macros have already been removed, but there was still some code handling these macros. That code is now removed.
