Skip to content

Conversation

flip1995
Copy link
Member

Niki4tap and others added 30 commits December 23, 2022 00:56
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 -->
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 -->
bors and others added 14 commits January 12, 2023 12:10
…, 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
Partially revert rust-lang#9701

This partially reverts rust-lang#9701 due to rust-lang#10134

r? `@flip1995`

changelog: None
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 12, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jan 12, 2023

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@Manishearth
Copy link
Member

@bors r+ p=1

@bors
Copy link
Collaborator

bors commented Jan 12, 2023

📌 Commit 01c7584 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 Jan 12, 2023
@bors
Copy link
Collaborator

bors commented Jan 12, 2023

⌛ Testing commit 01c7584 with merge 61a415b...

@bors
Copy link
Collaborator

bors commented Jan 12, 2023

☀️ Test successful - checks-actions
Approved by: Manishearth
Pushing 61a415b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 12, 2023
@bors bors merged commit 61a415b into rust-lang:master Jan 12, 2023
@rustbot rustbot added this to the 1.68.0 milestone Jan 12, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (61a415b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
0.8% [0.8%, 0.8%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.5%, -0.5%] 1
Improvements ✅
(secondary)
-2.3% [-2.5%, -2.1%] 2
All ❌✅ (primary) 0.2% [-0.5%, 0.8%] 2

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
1.7% [1.6%, 2.0%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.7% [1.6%, 2.0%] 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.