Clippy subtree update #117520
Merged
Clippy subtree update #117520
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Samuel Tardieu <sam@rfc1149.net>
Co-authored-by: Samuel Tardieu <sam@rfc1149.net> Co-authored-by: Catherine Flores <catherine.3.flores@gmail.com>
[`map_identity`]: recognize tuple identity function Fixes rust-lang#7189 This lint now recognizes `.map(|(a, b)| (a, b))` as a useless `map` call. changelog: [`map_identity`]: recognize tuple identity function
…r=llogiq
Skip if_not_else lint for '!= 0'-style checks
Currently, clippy makes unhelpful suggestions such as this:
```
warning: unnecessary `!=` operation
--> src/vm.rs:598:36
|
598 | *destination = if source & 0x8000 != 0 { 0xFFFF } else { 0 };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: change to `==` and swap the blocks of the `if`/`else`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#if_not_else
= note: `-W clippy::if-not-else` implied by `-W clippy::pedantic`
```
Bit tests often take on the form `if foo & 0x1234 != 0 { … } else { … }`, and the `!= 0` part reads as "has any bits set". Therefore, this code already has the "correct" order, and shouldn't be changed.
This PR disables the lint for these cases, and in fact all cases where the condition is "foo is non-zero".
I did my homework:
- \[X] Followed [lint naming conventions][lint_naming] → Not applicable, this PR fixes an existing lint
- \[X] Added passing UI tests (including committed `.stderr` file) → Yes, `tests/ui/if_not_else_bittest.rs`
- \[X] `cargo test` passes locally
- \[X] Executed `cargo dev update_lints`
- \[X] Added lint documentation → Not applicable, this PR fixes an existing lint
- \[X] Run `cargo dev fmt`
changelog: Fix [`if_not_else`] false positive when something like `bitflags != 0` is used
Avoid a `track_errors` by bubbling up most errors from `check_well_formed` I believe `track_errors` is mostly papering over issues that a sufficiently convoluted query graph can hit. I made this change, while the actual change I want to do is to stop bailing out early on errors, and instead use this new `ErrorGuaranteed` to invoke `check_well_formed` for individual items before doing all the `typeck` logic on them. This works towards resolving rust-lang#97477 and various other ICEs, as well as allowing us to use parallel rustc more (which is currently rather limited/bottlenecked due to the very sequential nature in which we do `rustc_hir_analysis::check_crate`) cc `@SparrowLii` `@Zoxc` for the new `try_par_for_each_in` function
suggest passing function instead of calling it in closure for [`option_if_let_else`] fixes: rust-lang#11429 changelog: suggest passing function instead of calling it in closure for [`option_if_let_else`]
Set doc-tests to `no_run` This excludes `should_panic` tests, those are still run to ensure they panic. Most of our other doc snippets don't gain much from being run though so this frees up a nice bit of CI time It also fixes the occasional issue such as `foo.txt`s being created https://github.com/rust-lang/rust-clippy/blob/f942470ca774b9648bac042f5d4c4ec74b81b61a/clippy_lints/src/permissions_set_readonly_false.rs#L19 changelog: none
report `unused_import` for empty reexports even it is pub Fixes rust-lang#116032 An easy fix. r? `@petrochenkov` (Discovered this issue while reviewing rust-lang#115993.)
Create `clippy_config` crate, hide internal representation from docs r? `@flip1995` The first commit moves a decent chunk of code out of `clippy_lints`/`clippy_utils` into a new crate `clippy_config` The second commit changes how `--explain`, the book and the site render configuration values. The internal type is now hidden and the displayed defaults are now valid TOML values instead of `Debug` output changelog: none
…rrors
Validate `feature` and `since` values inside `#[stable(…)]`
Previously the string passed to `#[unstable(feature = "...")]` would be validated as an identifier, but not `#[stable(feature = "...")]`. In the standard library there were `stable` attributes containing the empty string, and kebab-case string, neither of which should be allowed.
Pre-existing validation of `unstable`:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![unstable(feature = "kebab-case", issue = "none")]
#[unstable(feature = "kebab-case", issue = "none")]
pub struct Struct;
```
```console
error[E0546]: 'feature' is not an identifier
--> src/lib.rs:5:1
|
5 | #![unstable(feature = "kebab-case", issue = "none")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
For an `unstable` attribute, the need for an identifier is obvious because the downstream code needs to write a `#![feature(...)]` attribute containing that identifier. `#![feature(kebab-case)]` is not valid syntax and `#![feature(kebab_case)]` would not work if that is not the name of the feature.
Having a valid identifier even in `stable` is less essential but still useful because it allows for informative diagnostic about the stabilization of a feature. Compare:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![stable(feature = "kebab-case", since = "1.0.0")]
#[stable(feature = "kebab-case", since = "1.0.0")]
pub struct Struct;
```
```rust
// src/main.rs
#![feature(kebab_case)]
use repro::Struct;
fn main() {}
```
```console
error[E0635]: unknown feature `kebab_case`
--> src/main.rs:3:12
|
3 | #![feature(kebab_case)]
| ^^^^^^^^^^
```
vs the situation if we correctly use `feature = "snake_case"` and `#![feature(snake_case)]`, as enforced by this PR:
```console
warning: the feature `snake_case` has been stable since 1.0.0 and no longer requires an attribute to enable
--> src/main.rs:3:12
|
3 | #![feature(snake_case)]
| ^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
```
…ErrorGuaranteed`, even if that error is only emitted by `check_modwitem_types`
…affects_lint, r=Centri3 fix enum_variant_names depending lint depending on order changelog: [`enum_variant_names`]: fix single word variants preventing lint of later variant pre/postfixed with the enum name fixes rust-lang#11494 Single word variants prevented checking the `check_enum_start` and `check_enum_end` for being run on later variants
new lint: `unnecessary_fallible_conversions` Closes rust-lang#11577 A new lint that looks for calls such as `i64::try_from(1i32)` and suggests `i64::from(1i32)`. See lint description (and linked issue) for more details for why. There's a tiny bit of overlap with the `useless_conversion` lint, in that the other one warns `T::try_from(T)` (i.e., fallibly converting to the same type), so this lint ignores cases like `i32::try_from(1i32)` to avoid emitting two warnings for the same expression. Also, funnily enough, with this one exception, this lint would warn on exactly every case in the `useless_conversion_try` ui test that `useless_conversion` didn't cover (but never two warnings at the same time), which is neat. I did add an `#![allow]` though since we don't want interleaved warnings from multiple lints in the same uitest. changelog: new lint: `unnecessary_fallible_conversions`
Co-authored-by: Alejandra González <blyxyas@gmail.com>
This function was previously defined for the iter_kv_map, for_kw_map, and unused_enumerate_index lints. This commit extracts it into clippy_utils.
…blyxyas Add `unused_enumerate_index` lint A lint for unused `.enumerate()` indexes (`for (_, x) in iter.enumerate()`). I wasn't able to find a `rustc_span::sym::Enumerate`, so the code for checking that it's the correct `Enumerate` iterator is a bit weird. --- changelog: New lint: [`unused_enumerate_index`]: A new lint for checking that the indexes from `.enumerate()` calls are used. [rust-lang#10404](rust-lang/rust-clippy#10404) <!-- changelog_checked -->
Fix get_first false negative for VecDeque fixes rust-lang#11695 Also run the lint on `VecDeque` and suggest using `.front()` instead of `.get(0)` when trying to access the first element. PS: At first I implemented the VecDeque Lint in a separate `if_chain` (see the previous commit). Let me know if thats the preferred way, then I will remove the refactoring into one block. changelog: [`get_first`]: fix false negative: Also lint `VecDeque` and suggest using `front()`
In the updated nightly version, it seems that rustfmt now supports formatting let-chains. Since we're using them a lot, it's a lot of reformatting.
Rustup r? `@ghost` changelog: none
rustbot
added
the
S-waiting-on-review
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 3, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#117434 (delegate `<Box<E> as Error>::provide` to `<E as Error>::provide`) - rust-lang#117505 (Fix incorrect trait bound restriction suggestion) - rust-lang#117520 (Clippy subtree update) - rust-lang#117523 (oli-obk is on vacation) - rust-lang#117533 (Revert "bootstrap: do not purge docs on CI environment") r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 3, 2023
Rollup merge of rust-lang#117520 - flip1995:clippyup, r=Manishearth Clippy subtree update r? `@Manishearth`
bors-ferrocene bot
added a commit
to ferrocene/ferrocene
that referenced
this pull request
Nov 6, 2023
84: Automated pull from upstream `master` r=Dajamante a=github-actions[bot] This PR pulls the following changes from the upstream repository: * rust-lang/rust#117585 * rust-lang/rust#117576 * rust-lang/rust#96979 * rust-lang/rust#117191 * rust-lang/rust#117179 * rust-lang/rust#117574 * rust-lang/rust#117537 * rust-lang/rust#117608 * rust-lang/rust#117596 * rust-lang/rust#117588 * rust-lang/rust#117524 * rust-lang/rust#116017 * rust-lang/rust#117504 * rust-lang/rust#117469 * rust-lang/rust#116218 * rust-lang/rust#117589 * rust-lang/rust#117581 * rust-lang/rust#117503 * rust-lang/rust#117590 * rust-lang/rust#117583 * rust-lang/rust#117570 * rust-lang/rust#117562 * rust-lang/rust#117534 * rust-lang/rust#116894 * rust-lang/rust#110340 * rust-lang/rust#113343 * rust-lang/rust#117579 * rust-lang/rust#117094 * rust-lang/rust#117566 * rust-lang/rust#117564 * rust-lang/rust#117554 * rust-lang/rust#117550 * rust-lang/rust#117343 * rust-lang/rust#115274 * rust-lang/rust#117540 * rust-lang/rust#116412 * rust-lang/rust#115333 * rust-lang/rust#117507 * rust-lang/rust#117538 * rust-lang/rust#117533 * rust-lang/rust#117523 * rust-lang/rust#117520 * rust-lang/rust#117505 * rust-lang/rust#117434 * rust-lang/rust#117535 * rust-lang/rust#117510 * rust-lang/rust#116439 * rust-lang/rust#117508 Co-authored-by: Ben Wiederhake <BenWiederhake.GitHub@gmx.de> Co-authored-by: SabrinaJewson <sejewson@gmail.com> Co-authored-by: J-ZhengLi <lizheng135@huawei.com> Co-authored-by: koka <koka.code@gmail.com> Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com> Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com> Co-authored-by: lengyijun <sjtu5140809011@gmail.com> Co-authored-by: Zalathar <Zalathar@users.noreply.github.com> Co-authored-by: Oli Scherer <git-spam-no-reply9815368754983@oli-obk.de> Co-authored-by: Philipp Krones <hello@philkrones.com> Co-authored-by: y21 <30553356+y21@users.noreply.github.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: bohan <bohan-zhang@foxmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? @Manishearth