Clippy subtree update #129531

Jarcho · 2024-08-24T21:36:08Z

…items unless config allows it

…T_DOC_PARAGRAPH` lint

…ubtree-update

By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.

…=lcnr Miscellaneous improvements to struct tail normalization 1. Make checks for foreign tails more accurate by normalizing the struct tail. I didn't write a test for this one. 2. Normalize when computing struct tail for `offset_of` for slice/str. This fixes the new solver only. 3. Normalizing when computing tails for disaligned reference check. This fixes both solvers. r? lcnr

…ct_constructor_on_adt, r=Alexendoo Respect allow `inconsistent_struct_constructor` on the struct definition Closes rust-lang#13203 Now we check if the target type is marked with `#[allow(clippy:inconsistent_struct_constructor)]` before lining. As a side-effect of this change, The rule in the subject no longer runs on non-local `AdtDef`s. However, as suggested by `@Jarcho` it shouldn't be a big deal since most of the time we didn't have access to this information anyway. > You can't get lint attributes from other crates. I would probably just restrict the lint to only work with types from the current crate while you're at it. Upstream crates don't have a definition order from the point of view of the current crate (with the exception of #[repr(C)] structs). changelog: Respect allow `inconsistent_struct_constructor` on the struct definition.

…ext` which returns a displayable string-like type.

* Check the path length first * Use `is_from_proc_macro` * Use symbols instead of strings when checking crate names

Refactor `absolute_paths` Checks are rearranged to do the more expensive checks later. Since the most likely path length will be one (locals and imported/local items) this will exclude such paths on the first check. Tests were rewritten as they were hard to follow (annotations would have helped), spammy (lots of tests for the same thing) and insufficient. One thing thing that came up and should be decided on now is what to do about the difference between `path::to::Trait::item` (4 segments) and `path::to::Type::item` (3 segments). The current behaviour treats these as different lengths which is terrible. I personally think these should both be three segments since the item can't actually be imported. Only the type or the trait could be. This makes `crate_name::Trait::item` the shortest absolute path which is shorter than the lint allows by default. changelog: None

[`macro_metavars_in_unsafe`]: recognize metavariables in tail expressions Fixes rust-lang#13219 `macro_metavars_in_unsafe` keeps track of the current "expansion depth" (incremented/decremented when entering/leaving a macro span) to tell if an expression from the root context is contained within a macro (see the doc comment I added for a hopefully better explanation) Before this PR, we didn't increment said `expn_depth` for `unsafe` blocks within macros, because we already do that in `visit_stmt` anyway, so it would work fine for statements, but that's not enough for tail expressions of an unsafe block. So we now also increment it for macro unsafe blocks. Also updated the comment for `expn_depth` while I'm at it because "This is not necessary for correctness" isn't correct now that I think about it ------ changelog: none

Fix case where doc_markdown is triggered on words ending with "ified" Fixes rust-lang#13097. r? `@Alexendoo` changelog: Fix case where doc_markdown is triggered on words ending with "ified"

rustbot · 2024-08-24T21:36:20Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

Manishearth · 2024-08-24T22:22:53Z

r=me in theory, needs CI fixes and the removal of merge commits

rustbot · 2024-08-24T22:33:59Z

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.

rustbot · 2024-08-24T22:34:00Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits (since this message was last posted):

6c3f43d

Jarcho · 2024-08-24T22:50:06Z

Aren't the merge commits normal? They're all bors commits or subtree merges.

Manishearth · 2024-08-24T23:45:32Z

ah hmm maybe. I've not seen that comment before

Jarcho · 2024-08-25T01:47:27Z

Looks like the name of the PR is the problem going by https://forge.rust-lang.org/triagebot/no-merge.html and

rust/triagebot.toml

Line 551 in f167efa

exclude_titles = ["Rollup of", "subtree update", "Subtree update"]

Manishearth · 2024-08-25T05:49:29Z

Aha, that works then

@bors r+ p=1 rollup=iffy

bors · 2024-08-25T05:49:32Z

📌 Commit 6c3f43d has been approved by Manishearth

It is now in the queue for this repository.

bors · 2024-08-25T11:57:14Z

⌛ Testing commit 6c3f43d with merge 8910346...

bors · 2024-08-25T14:19:47Z

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

rust-timer · 2024-08-25T15:34:42Z

Finished benchmarking commit (8910346): 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 (secondary 0.4%)

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
Regressions ❌ (secondary)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 2.3%, secondary -2.1%)

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)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	1
All ❌✅ (primary)	2.3%	[2.3%, 2.3%]	1

Binary size

Results (secondary 0.0%)

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
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Bootstrap: 750.871s -> 751.721s (0.11%)
Artifact size: 338.73 MiB -> 338.75 MiB (0.01%)

Rust 1.82.0's Clippy is introducing [1][2] a new lint, `too_long_first_doc_paragraph` [3], which is intended to catch titles of code documentation items that are too long (likely because no title was provided and the item documentation starts with a paragraph). This lint does not currently trigger anywhere, but it does detect a couple cases we had in private cases if checking for private items gets enabled (which we will do in the next commit): error: first doc comment paragraph is too long --> rust/kernel/init/__internal.rs:18:1 | 18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this 19 | | /// type, since the closure needs to fulfill the same safety requirement as the 20 | | /// `__pinned_init`/`__init` functions. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph = note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]` error: first doc comment paragraph is too long --> rust/kernel/sync/arc/std_vendor.rs:3:1 | 3 | / //! The contents of this file come from the Rust standard library, hosted in 4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under 5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details, 6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph Thus clean the two instances we hit and enable the lint. In addition, since we have have a second `std_vendor.rs` file with a similar header, do the same there too (even if that one does not trigger the lint, because it is `doc(hidden)`). Link: rust-lang/rust#129531 [1] Link: rust-lang/rust-clippy#12993 [2] Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Rust 1.82.0's Clippy is introducing [1][2] a new warn-by-default lint, `too_long_first_doc_paragraph` [3], which is intended to catch titles of code documentation items that are too long (likely because no title was provided and the item documentation starts with a paragraph). This lint does not currently trigger anywhere, but it does detect a couple cases we had in private cases if checking for private items gets enabled (which we will do in the next commit): error: first doc comment paragraph is too long --> rust/kernel/init/__internal.rs:18:1 | 18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this 19 | | /// type, since the closure needs to fulfill the same safety requirement as the 20 | | /// `__pinned_init`/`__init` functions. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph = note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]` error: first doc comment paragraph is too long --> rust/kernel/sync/arc/std_vendor.rs:3:1 | 3 | / //! The contents of this file come from the Rust standard library, hosted in 4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under 5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details, 6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph Thus clean the two instances we hit and enable the lint. In addition, since we have have a second `std_vendor.rs` file with a similar header, do the same there too (even if that one does not trigger the lint, because it is `doc(hidden)`). Link: rust-lang/rust#129531 [1] Link: rust-lang/rust-clippy#12993 [2] Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Rust 1.82.0's Clippy is introducing [1][2] a new warn-by-default lint, `too_long_first_doc_paragraph` [3], which is intended to catch titles of code documentation items that are too long (likely because no title was provided and the item documentation starts with a paragraph). This lint does not currently trigger anywhere, but it does detect a couple cases we had in private cases if checking for private items gets enabled (which we will do in the next commit): error: first doc comment paragraph is too long --> rust/kernel/init/__internal.rs:18:1 | 18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this 19 | | /// type, since the closure needs to fulfill the same safety requirement as the 20 | | /// `__pinned_init`/`__init` functions. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph = note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]` error: first doc comment paragraph is too long --> rust/kernel/sync/arc/std_vendor.rs:3:1 | 3 | / //! The contents of this file come from the Rust standard library, hosted in 4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under 5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details, 6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph Thus clean the two instances we hit and enable the lint. In addition, since we have a second `std_vendor.rs` file with a similar header, do the same there too (even if that one does not trigger the lint, because it is `doc(hidden)`). Link: rust-lang/rust#129531 [1] Link: rust-lang/rust-clippy#12993 [2] Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Clippy subtree update r? `@Manishearth`

Rust 1.82.0's Clippy is introducing [1][2] a new warn-by-default lint, `too_long_first_doc_paragraph` [3], which is intended to catch titles of code documentation items that are too long (likely because no title was provided and the item documentation starts with a paragraph). This lint does not currently trigger anywhere, but it does detect a couple cases if checking for private items gets enabled (which we will do in the next commit): error: first doc comment paragraph is too long --> rust/kernel/init/__internal.rs:18:1 | 18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this 19 | | /// type, since the closure needs to fulfill the same safety requirement as the 20 | | /// `__pinned_init`/`__init` functions. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph = note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]` error: first doc comment paragraph is too long --> rust/kernel/sync/arc/std_vendor.rs:3:1 | 3 | / //! The contents of this file come from the Rust standard library, hosted in 4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under 5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details, 6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>. | |_ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph Thus clean those two instances. In addition, since we have a second `std_vendor.rs` file with a similar header, do the same there too (even if that one does not trigger the lint, because it is `doc(hidden)`). Link: rust-lang/rust#129531 [1] Link: rust-lang/rust-clippy#12993 [2] Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [3] Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240904204347.168520-15-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

GuillaumeGomez and others added 30 commits July 26, 2024 11:12

Fix case where doc_markdown is triggered on words ending with "ified"

760c3fa

Add regression test for rust-lang#13097

88506a9

Add new too_long_first_doc_paragraph first paragraph lint

855a9d1

Set the limit of characters to 200 and don't run the lint on private …

f455587

…items unless config allows it

Fix dogfood lints

4969960

Add comment explaining what the matching items are for `TOO_LONG_FIRS…

3c6e5ef

…T_DOC_PARAGRAPH` lint

Move style into its file

b7e7975

Add new settings menu

7c52091

Fix example

8bf5a83

Respect allow inconsistent_struct_constructor on the type definition

5364cbe

recognize metavariables in tail expressions

234a1d3

add a test for ice-3717.rs

5e25e7c

rust-lang/rust-clippy#13099

Rename struct_tail_erasing_lifetimes to struct_tail_for_codegen

6ce7e6d

Merge commit 'cb806113e0f83a8f9b47d35b453b676543bcc40e' into clippy-s…

1ac76a2

…ubtree-update

Fix confusing message in double_must_use lint

9948b42

use fulfill_or_allowed over is_lint_allowed.

d85cf0b

Replace rustc_semver with rustc_session::RustcVersion

b32a017

Rename get_source_text to get_source_range. Add new `get_source_t…

9afab36

…ext` which returns a displayable string-like type.

Paper over the clippy ICE

dda9eb9

Refactor absolute_paths:

f9509d3

* Check the path length first * Use `is_from_proc_macro` * Use symbols instead of strings when checking crate names

Fixes in various places

917ad03

Remove find_format_arg_expr AST fallback

4231e93

Auto merge of rust-lang#13163 - GuillaumeGomez:fix-13097, r=Alexendoo

c8b0923

Fix case where doc_markdown is triggered on words ending with "ified" Fixes rust-lang#13097. r? `@Alexendoo` changelog: Fix case where doc_markdown is triggered on words ending with "ified"

lintcheck: key lints on line start rather than byte start/end

6de27a0

Link std statically in rustc_driver

837d904

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 24, 2024

This comment has been minimized.

Sign in to view

Merge commit '0f8eabd6231366bfc1bb1464601297c2d48f8f68' into clippyup

6c3f43d

Jarcho force-pushed the clippyup branch from 4a91a13 to 6c3f43d Compare August 24, 2024 22:33

Jarcho changed the title ~~Clippyup~~ Clippy subtree update Aug 25, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 25, 2024

bors merged commit 8910346 into rust-lang:master Aug 25, 2024
7 checks passed

rustbot added this to the 1.82.0 milestone Aug 25, 2024

flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 5, 2024

Auto merge of rust-lang#129531 - Jarcho:clippyup, r=Manishearth

508a7b4

Clippy subtree update r? `@Manishearth`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clippy subtree update #129531

Clippy subtree update #129531

Jarcho commented Aug 24, 2024

rustbot commented Aug 24, 2024

This comment has been minimized.

Manishearth commented Aug 24, 2024

rustbot commented Aug 24, 2024

rustbot commented Aug 24, 2024

Jarcho commented Aug 24, 2024

Manishearth commented Aug 24, 2024

Jarcho commented Aug 25, 2024 •

edited

Loading

Manishearth commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

rust-timer commented Aug 25, 2024

Clippy subtree update #129531

Clippy subtree update #129531

Conversation

Jarcho commented Aug 24, 2024

rustbot commented Aug 24, 2024

This comment has been minimized.

Manishearth commented Aug 24, 2024

rustbot commented Aug 24, 2024

rustbot commented Aug 24, 2024

Jarcho commented Aug 24, 2024

Manishearth commented Aug 24, 2024

Jarcho commented Aug 25, 2024 • edited Loading

Manishearth commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

bors commented Aug 25, 2024

rust-timer commented Aug 25, 2024

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Jarcho commented Aug 25, 2024 •

edited

Loading