Update Clippy #106780
Merged
Update Clippy #106780
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
The name makes a lot more sense, and `ty::TyKind` calls it `Ref` already as well.
Instead of
```
LL | fn oom(
| __^
| | _|
| ||
LL | || ) {
| ||_-
LL | | }
| |__^
```
emit
```
LL | // fn oom(
LL | || ) {
| ||_-
LL | | }
| |__^
```
Update Clippy r? `@Manishearth` I think this was the very first sync with no conflicts whatsoever. I love this time of the year :D
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#104531 (Provide a better error and a suggestion for `Fn` traits with lifetime params) - rust-lang#105899 (`./x doc library --open` opens `std`) - rust-lang#106190 (Account for multiple multiline spans with empty padding) - rust-lang#106202 (Trim more paths in obligation types) - rust-lang#106234 (rustdoc: simplify settings, help, and copy button CSS by not reusing) - rust-lang#106236 (docs/test: add docs and a UI test for `E0514` and `E0519`) - rust-lang#106259 (Update Clippy) - rust-lang#106260 (Fix index out of bounds issues in rustdoc) - rust-lang#106263 (Formatter should not try to format non-Rust files) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Move `mutex_atomic` to `restriction` By rust-lang#4295, the general consensus seems to be that `mutex_atomic` is not a useful lint in most cases. If anything, it could be useful as a restriction on code that for whatever reason can't use atomics. Keeping it in `clippy::nursery` is harmful to people attempting to use clippy for soundness. --- changelog: Moved [`mutex_atomic`] to `restriction` [rust-lang#10115](rust-lang/rust-clippy#10115) <!-- chnagelog_checked -->
…exendoo Fix FN in `needless_return` Fixes rust-lang#10051 changelog: Enhancement: [`needless_return`]: Now detects more cases for returns of owned values [rust-lang#10110](rust-lang/rust-clippy#10110) <!-- changelog_checked -->
This commit makes the ContainsName struct visit all interior expressions, which means that ContainsName will return true even if `name` is used in a closure within `expr`.
Correct Gankra's name in the linkedlist lint changelog: [`linkedlist`]: Update description
…Jarcho chore: fix identation of `if_chain` in `filter_map` This is a really small fix. If someone could take a look at it, I would appreciate it:pray: --- changelog: none <!-- changelog_checked -->
Fix typo in `unused_self` diagnostic message changelog: Msg: [`unused_self`]: The message now correctly uses *an* [rust-lang#10138](rust-lang/rust-clippy#10138) <!-- changelog_checked -->
Signed-off-by: Tyler Weaver <[email protected]>
Signed-off-by: Tyler Weaver <[email protected]>
we only need to check closures, so nestedfilter::All was overkill here.
…t-FP, r=Manishearth don't lint field_reassign when field in closure fixes rust-lang#10136 This change makes the ContainsName struct visit all interior expressions, which means that ContainsName will return true even if `name` is used in a closure within `expr`. --- changelog: FP: [`field_reassign_with_default`]: No longer lints cases, where values are initializes from closures capturing struct values [rust-lang#10143](rust-lang/rust-clippy#10143) <!-- changelog_checked -->
fix empty_structs_with_brackets suggestion errors fixes rust-lang#9887 I refer to [my comment](rust-lang/rust-clippy#9887 (comment)) to explain this PR. --- changelog: Sugg: [`empty_structs_with_brackets`]: The suggestion is no longer machine applicable, to avoid errors when accessing struct fields [rust-lang#10141](rust-lang/rust-clippy#10141) <!-- changelog_checked -->
…, r=xFrednet trim paths in `suspicious_to_owned` This continues my path trimming spree. I'm not going to add yet another changelog entry, we should have one "trim paths in some applicable lints" entry instead. --- changelog: none
Allow implementing `Hash` with derived `PartialEq` (`derive_hash_xor_eq` This is a common pattern and is totally allowed by the `Hash` trait. Fixes rust-lang#2627 changelog: Move: Renamed `derive_hash_xor_eq` to [`derived_hash_with_manual_eq`] [rust-lang#10184](rust-lang/rust-clippy#10184) changelog: Enhancement: [`derived_hash_with_manual_eq`]: Now allows `#[derive(PartialEq)]` with custom `Hash` implementations [rust-lang#10184](rust-lang/rust-clippy#10184) <!-- changelog_checked -->
This is useful for rust-lang/rust to allow setting a sysroot that's *only* for build scripts, different from the regular sysroot passed in RUSTFLAGS (since cargo doesn't apply RUSTFLAGS to build scripts or proc-macros). That said, the exact motivation is not particularly important: this fixes a regression from rust-lang/rust-clippy@5907e91#r1060215684. Note that only RUSTFLAGS is tested in the new integration test; passing --sysroot through `clippy-driver` never worked as far as I can tell, and no one is using it, so I didn't fix it here.
Whne SYSROOT is defined, clippy-driver will insert a --sysroot argument when calling rustc. However, when a sysroot argument is already defined, e.g. through RUSTFLAGS=--sysroot=... the `cargo clippy` call would error. This tests that the sysroot argument is only passed once and that SYSROOT is ignored in this case.
Don't pass `--sysroot` twice if SYSROOT is set This is useful for rust-lang/rust to allow setting a sysroot that's *only* for build scripts, different from the regular sysroot passed in RUSTFLAGS (since cargo doesn't apply RUSTFLAGS to build scripts or proc-macros). That said, the exact motivation is not particularly important: this fixes a regression from rust-lang/rust-clippy@5907e91#r1060215684. Note that only RUSTFLAGS is tested in the new integration test; passing --sysroot through `clippy-driver` never worked as far as I can tell, and no one is using it, so I didn't fix it here. Helps with rust-lang#106394. --- changelog: other: `SYSROOT` and `--sysroot` can now be set at the same time [rust-lang#10149](rust-lang/rust-clippy#10149) <!-- changelog_checked -->
I'm not sure why this is necessary. It worked without this for me locally, but this fails in CI. The same was done in clippy_dev
Rustup r? `@ghost` changelog: none
Partially revert rust-lang#9701 This partially reverts rust-lang#9701 due to rust-lang#10134 r? `@flip1995` changelog: None
rustbot
added
the
S-waiting-on-review
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
@bors r+ p=1 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (61a415b): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
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