Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clippy subtree update #117520

Merged
merged 77 commits into from
Nov 3, 2023
Merged

Clippy subtree update #117520

merged 77 commits into from
Nov 3, 2023

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Nov 2, 2023

BenWiederhake and others added 30 commits June 25, 2023 23:39
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`
bors and others added 15 commits October 31, 2023 01:33
…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.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 2, 2023
@rustbot
Copy link
Collaborator

rustbot commented Nov 2, 2023

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@Manishearth
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 3, 2023

📌 Commit 02562bf has been approved by Manishearth

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 3, 2023
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
@bors bors merged commit 9028ce3 into rust-lang:master Nov 3, 2023
11 checks passed
@rustbot rustbot added this to the 1.75.0 milestone Nov 3, 2023
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`
@flip1995 flip1995 deleted the clippyup branch November 3, 2023 17:34
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
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.