bors [Fri, 20 May 2022 21:35:14 +0000 (21:35 +0000)]
Auto merge of #8856 - xFrednet:rustup, r=Manishearth,Alexendoo
Rustup
`@rust-lang/clippy,` `@Jarcho,` `@dswij,` `@Alexendoo.` Could someone review this? It should be pretty straight forward since it's just a sync. I think it's also fine if either one of `@Jarcho,` `@dswij,` `@Alexendoo` approves this, as these are usually not reviewed. I just want to make sure that I didn't break something obvious :upside_down_face:
It should be enough to look at the merge commit :upside_down_face:
changelog: none
changelog: move [`significant_drop_in_scrutinee`] to `suspicious`
bors [Thu, 19 May 2022 21:46:18 +0000 (21:46 +0000)]
Auto merge of #8841 - Serial-ATA:remove-code-block, r=xFrednet
Remove code block from `pub_enum_variant_names`
changelog: none
Just noticed this empty code block that no other lint has :smile:.
![old](https://user-images.githubusercontent.com/69764315/169314573-098ce938-8a4c-4451-afd7-7b082823a0de.png)
bors [Thu, 19 May 2022 20:02:29 +0000 (20:02 +0000)]
Auto merge of #8840 - xFrednet:0000-mini-changelog-update, r=llogiq
Mini changelog update for Rust 1.61.0
I'll do the full release and sync tomorrow, as I sadly don't have the time today. This is a quick update to ensure that Rust's changelog will link to the correct section in our changelog. The change is according to [our docs](https://github.com/rust-lang/rust-clippy/blob/8751e47bae68f6bf7ec833dbd42bde51a74f1a65/book/src/development/infrastructure/release.md#update-changelogmd)
You can test this by (say) adding `foobar = 42` to Clippy's root `clippy.toml` file, and running `cargo run --bin cargo-clippy`.
Note that, to get the terminal width, this PR adds `termize` as a dependency to `cargo-clippy`. However, `termize` is also [how `rustc_errors` gets the terminal width](https://github.com/rust-lang/rust/blob/481db40311cdd241ae4d33f34f2f75732e44d8e8/compiler/rustc_errors/src/emitter.rs#L1607). So, hopefully, this is not a dealbreaker.
r? `@xFrednet`
changelog: Enhancements: the "unknown field" error messages for config files now wraps the field names.
Yuki Okushi [Tue, 17 May 2022 10:01:32 +0000 (19:01 +0900)]
Rollup merge of #97079 - SparrowLii:successors, r=lcnr
Change `Successors` to `impl Iterator<Item = BasicBlock>`
This PR fixes the FIXME in `compiler\rustc_middle\src\mir\mod.rs`.
This can omit several `&`, `*` or `cloned` operations on Successros' generated elements
bors [Tue, 17 May 2022 05:46:00 +0000 (05:46 +0000)]
Auto merge of #8814 - yonip23:add-suggestion-to-rc-clone-in-vec-init, r=xFrednet
add suggestions to rc_clone_in_vec_init
A followup to https://github.com/rust-lang/rust-clippy/pull/8769
I also switch the order of the 2 suggestions, since the loop initialization one is probably the common case.
`@xFrednet` I'm not letting you guys rest for a minute 😅
changelog: add suggestions to [`rc_clone_in_vec_init`]
I've split this into two commits, in the second one I moved the JS into its own file to make it easier to work on. Is that alright? And if so, could the same thing be done to the css?
bors [Mon, 16 May 2022 00:47:10 +0000 (00:47 +0000)]
Auto merge of #8761 - tamaroning:fix_8505, r=Jarcho
`undocumented_unsafe_blocks` does not trigger on unsafe trait impls
Closes #8505
changelog: This lint checks unsafe impls NOT from macro expansions and checks ones in macro declarations.
~~`unsafe impl`s from macro invocations don't trigger the lint for now.~~
~~This lint checks unsafe impls from/not from macro expansions~~
bors [Sun, 15 May 2022 21:51:24 +0000 (21:51 +0000)]
Auto merge of #8699 - Jarcho:vec_init_then_push_7071, r=dswij,xFrednet
Don't lint `vec_init_then_push` when further extended
fixes #7071
This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.
changelog: Don't lint `vec_init_then_push` when further extended.
changelog: Remove `mut` binding from `vec_init_then_push` when possible.
bors [Sun, 15 May 2022 03:52:37 +0000 (03:52 +0000)]
Auto merge of #8832 - Alexendoo:duplicate-mod, r=Manishearth
Add `duplicate_mod` lint
Inspired by #8827, warns if there's a single file that is loaded by more than one `mod` item
```rust,ignore
// lib.rs
mod a;
mod b;
```
```rust,ignore
// a.rs
#[path = "./b.rs"]
mod b;
```
It adds a `canonicalize` call per `mod file;` encountered, which I don't think should be too heavy
Integration tests with common modules, e.g. [`test_utils`](https://github.com/rust-lang/rust-clippy/tree/2038084cf2253b57cf8b405ab000a92b68346f43/tests/test_utils) doesn't trigger it as each test is compiled separately, however I couldn't figure out a good way to add a test for that
bors [Sat, 14 May 2022 23:53:11 +0000 (23:53 +0000)]
Auto merge of #96883 - jackh726:early-binder-2, r=oli-obk
Add EarlyBinder
Chalk has no concept of `Param` (https://github.com/rust-lang/chalk/blob/e0ade19d139bc784384acc6736cd960c91dd55a1/chalk-ir/src/lib.rs#L579) or `ReEarlyBound` (https://github.com/rust-lang/chalk/blob/e0ade19d139bc784384acc6736cd960c91dd55a1/chalk-ir/src/lib.rs#L1308). Everything is just "bound" - the equivalent of rustc's late-bound. It's not completely clear yet whether to move everything to the same time of binder in rustc or add `Param` and `ReEarlyBound` in Chalk.
Either way, tracking when we have or haven't already substituted out these in rustc can be helpful.
As a first step, I'm just adding a `EarlyBinder` newtype that is required to call `subst`. I also add a couple "transparent" `bound_*` wrappers around a couple query that are often immediately substituted.
bors [Fri, 13 May 2022 06:03:39 +0000 (06:03 +0000)]
Auto merge of #8825 - ydah:fix_spelling, r=giraffate
Tweak some words improved representation
Hello! Thank you for this awesome project!
This PR has implemented improved representation.
- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"
ydah [Fri, 13 May 2022 05:20:25 +0000 (14:20 +0900)]
Tweak some words improved representation
This PR has implemented improved representation.
- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"
bors [Thu, 12 May 2022 23:56:31 +0000 (23:56 +0000)]
Auto merge of #8799 - Alexendoo:lintcheck-common, r=giraffate
Some lintcheck cleanup
A grab bag of smaller changes:
Panics if a crate source isn't valid, and fixes the `ryu` crate entry so it's picked up. Took me a while to realise why I couldn't do `cargo lintcheck --only ryu` 😅
Parses messages with `cargo_metadata`, this catches a few more lints that were ignored because the message had an [expansion field](https://docs.rs/cargo_metadata/latest/cargo_metadata/diagnostic/struct.DiagnosticSpanMacroExpansion.html) that contained a path pointing into `.../.toolchains/...`. It also no longer emits some log lines with `null` as the column
It also merges the `run_clippy_lint` invocations and splits `LintcheckConfig` out into its own file
bors [Thu, 12 May 2022 12:48:30 +0000 (12:48 +0000)]
Auto merge of #95562 - lcnr:attr-no-encode, r=davidtwco
don't encode only locally used attrs
Part of https://github.com/rust-lang/compiler-team/issues/505.
We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR.
After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.
cc https://github.com/rust-lang/rust/pull/94963#issuecomment-1082924289
bors [Mon, 9 May 2022 19:55:37 +0000 (19:55 +0000)]
Auto merge of #8809 - Alexendoo:metadata-collection-expect, r=xFrednet
Ignore unfulfilled_lint_expectations in metadata collection
r? `@xFrednet`
When metadata collection is enabled the regular early/late pass registrations are skipped, which the `#[expect()]`s were no fan of: https://github.com/rust-lang/rust-clippy/runs/6356675328?check_suite_focus=true
bors [Mon, 9 May 2022 17:14:43 +0000 (17:14 +0000)]
Auto merge of #8797 - xFrednet:0000-expect-a-playground, r=flip1995
Replace `#[allow]` with `#[expect]` in Clippy
Hey `@rust-lang/clippy,` `@Alexendoo,` `@dswij,` I'm currently working on the expect attribute as defined in [Rust RFC 2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). With that, an `#[allow]` attribute can be replaced with a `#[expect]` attribute that suppresses the lint, but also emits a warning, if the lint isn't emitted in the expected scope.
With this PR I would like to test the attribute on a project scale and Clippy obviously came to mind. This PR replaces (almost) all `#[allow]` attributes in `clippy_utils` and `clippy_lints` with the `#[expect]` attribute. I was also able to remove some allows since, the related FPs have been fixed :tada:.
My question is now, are there any concerns regarding this? It's still okay to add normal `#[allow]` attributes, I see the need to nit-pick about that in new PRs, unless it's actually a FP. Also, I would not recommend using `#[expect]` in tests, as changes to a lint could the trigger the expect attribute in other files.
Additionally, I've noticed that Clippy has a bunch of `#[allow(clippy::too_many_lines)]` attributes. Should we maybe allow the lint all together or increase the threshold setting? To me, it seems like we mostly just ignore it in our code. :sweat_smile: :upside_down_face:
---
changelog: none
r? `@flip1995` (I've requested you for now, since you're also helping with reviewing the expect implementation. You are welcome to delegate this PR, even if it should be a simple review :upside_down_face: )
bors [Mon, 9 May 2022 13:56:53 +0000 (13:56 +0000)]
Auto merge of #8805 - Alexendoo:let-chain-docs, r=flip1995
Recommend let chains over if_chain in docs
Switches over bit_mask.rs to let chains in order to create a nice example
While the rustfmt thing isn't resolved yet, my rust-analyzer isn't a fan of large `if_chains!`s, it stops giving me hover info and such after some number of if statements
bors [Mon, 9 May 2022 00:02:55 +0000 (00:02 +0000)]
Auto merge of #95542 - xFrednet:rfc-2383-expect-query, r=wesleywiser
Support tool lints with the `#[expect]` attribute (RFC 2383)
This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional.
Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.
The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. :sauropod:
bors [Sun, 8 May 2022 15:00:30 +0000 (15:00 +0000)]
Auto merge of #8802 - smoelius:allow-expect-unwrap-in-tests, r=llogiq
Optionally allow `expect` and `unwrap` in tests
This addresses #1015, except it makes the new behavior optional.
The reason for the msrv-related changes is as follows.
Rather than expand `check_methods` list of arguments, it seemed easier to make `check_methods` a method of `Methods`, so that `check_methods` could access `Methods`' fields.
`check_methods` had an `msrv` parameter, which I consequently made a field of `Methods`. But, to avoid adding a lifetime parameter to `Methods`, I made the field type `Option<RustcVersion>` instead of the parameter's existing type, `Option<&RustcVersion>`. This seemed sensible since `RustcVersion` implements `Copy`. But this broke a lot of code that expected an `Option<&RustcVersion>` or `&Option<RustcVersion>`. I changed all of those occurrences to `Option<RustcVersion>`. IMHO, the code is better as a result of these changes, though.
The msrv-related changes are in their own commit to (hopefully) ease review.
Closes #1015
changelog: optionally allow `expect` and `unwrap` in tests
bors [Sun, 8 May 2022 14:10:12 +0000 (14:10 +0000)]
Auto merge of #96770 - flip1995:fix-trait-type-in-bounds, r=cjgillot
Track if a where bound comes from a impl Trait desugar
With https://github.com/rust-lang/rust/pull/93803 `impl Trait` function arguments get desugared to hidden where bounds. However, Clippy needs to know if a bound was originally a `impl Trait` or an actual bound. This adds a field to the `WhereBoundPredicate` struct to keep track of this information during AST->HIR lowering.