Changelog for Clippy 1.80 🌞
Roses are red,
Violets are blue,
Summer is fun,
So much sun
---
### The cat of this release is *Maunzer* submitted by `@llogiq:`
<img height=500 src="https://github.com/rust-lang/rust-clippy/assets/4200835/a1da6948-446d-4ccf-95a7-c816a8afdc3f" alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
changelog: none
I wish everyone reading this a beautiful and happy day =^.^=
Lintcheck: Rework and limit diff output for GH's CI
### Background
While working on https://github.com/rust-lang/rust-clippy/pull/13136 I found an amazing limitation of GH's CI. The summary can at most have be 1MB of text. Here is the warning message:
> $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 46731k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary
[The PR](https://github.com/rust-lang/rust-clippy/pull/13136) produced a *casual* 61808 changes. Guess that's why those lints are not *warn-by-default* :P.
### Changes:
This PR limits the lintcheck diff output in two ways.
1. The diff is limited to 200 messages per lint per section. Hidden messages are indicated by a message at the end of the section.
2. The output is first written to a file and only the first 1MB is written to ` >> $GITHUB_STEP_SUMMARY`. The entire file is also written to the normal CI log. This helps for cases where several lints change and the total size exceeds the 1MB limit.
An example of these changes can be seen here: https://github.com/xFrednet/rust-clippy/actions/runs/10028799118?pr=4
---
changelog: none
r? `@Alexendoo`
Sorry for bombarding you with so many PR's lately 😅 Feel free to pass some of you reviews to me.
Use ControlFlow in more places
Now, instead of manually using variables in visitors to signify that a visit is "done" and that the visitor should stop traversing. We use the trait type "Result" to signify this (in relevant places).
I'll schedule a perf run, I don't think it will be much of a difference, but every bit of performance is welcomed :)
changelog: Improve performance, less memory use in visitors
Fixes#12829
r? `@y21`
Make ast `MutVisitor` have the same method name and style as `Visitor`
It doesn't map 100% because some `MutVisitor` methods can filter or even expand to multiple items, but consistency seems nicer.
tracking issue: https://github.com/rust-lang/rust/issues/127615
Fix running compile-test under cargo nextest
`ui_test` itself has `cargo nextest` support which we now use - https://github.com/oli-obk/ui_test/pull/161
It prints `ui_test` as its test name whereas we printed `compile_test`, this ended up being treated as a test name filter causing all the tests to be filtered out
changelog: none
Temporarily remove myself from reviewer rotation
I'm going to focus on the project goal and my own contributions, this + medical stuff leaves me not enough time to review.
I'll still review any performance related PR, and you can still request from me a benchmark for a PR, and will finish the PRs that I'm still assign to.
changelog: none
Misc refactorings
Various small re-orderings to check the HIR tree or AST before doing other checks. Also includes a small bug fix for `arc_with_small_send_sync` not actually checking for `Arc::new`.
changelog: none
Misc refactorings part 5
`toplevel_ref_arg` gets a small fix so it can be allowed on function arguments. Otherwise just some rearrangements.
changelog: none
add lint for recreation of an entire struct
This lint makes Clippy warn about situations where an owned struct is
essentially recreated by moving all its fields into a new instance of
the struct. The lint is not machine-applicable because the source
struct may have been partially moved.
This lint originated in something I spotted during peer review. While
working on their branch a colleague ended up with a commit where a
function returned a struct that 1:1 replicated one of its owned inputs
from its members. Initially I suspected they hadn’t run their code
through Clippy but AFAICS there is no lint for this situation yet.
changelog: new lint: [`redundant_owned_struct_recreation`]
### New lint checklist
- \[+] Followed [lint naming conventions][lint_naming]
- \[+] Added passing UI tests (including committed `.stderr` file)
- \[+] `cargo test` passes locally
- \[+] Executed `cargo dev update_lints`
- \[+] Added lint documentation
- \[+] Run `cargo dev fmt`
Remove unnecessary impl sorting in queries and metadata
Removes unnecessary impl sorting because queries already return their keys in HIR definition order: https://github.com/rust-lang/rust/issues/120371#issuecomment-1926422838
r? `@cjgillot` or `@lcnr` -- unless I totally misunderstood what was being asked for here? 😆fixes#120371
[`pathbuf_init_then_push`]: Checks for calls to `push` immediately a…
changelog: [`pathbuf_init_then_push`]: new lint: Checks for calls to `push` immediately after creating a new `PathBuf`
Just a mirror of VEC_INIT_THEN_PUSH
Lintcheck: Update crates and expand CI testset to 200 crates
This PR adds a new `ci_crates.toml` to lintcheck for our CI. The 200 crates take about 14 minutes, which is slightly more than the 10 I aimed for but still reasonable. The testset is constructed from:
* 5 crates that compile to binaries
* 4 crates that have been mentioned in ICE issues
* 1 crates "random" crates from `lintcheck_crates.toml`
* 190 crates from the top 200 crates from crates.io
During testing, I noticed a few panics in lintcheck. I've fixed them where possible, or at least improved the error message.
The new test set generates 500+ MB of json lints, which are compressed to a ~24mb artifact.
---
This PR also updates our `lintcheck_crates.toml`. I mainly updated the versions, removed some very outdated crates, and added some new ones. I targeted 25 crates as those are pretty fast to lint and a good precursor for our CI.
---
Optional TODO:
* It's likely that some crates are compiled several times. We could potentially safe some time, by using `--recursive` in our CI.
This is something I want to investigate, but it shouldn't be a blocker for this PR.
---
r? `@Alexendoo`
changelog: none
Represent type-level consts with new-and-improved `hir::ConstArg`
### Summary
This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:
- Add `current_def_id_parent` to `LoweringContext`
This is needed to track anon const parents properly once we implement
`ConstArgKind::Path` (which requires moving anon const def-creation
outside of `DefCollector`).
- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.
- Use `ConstArg` for all instances of const args. Specifically, use it instead
of `AnonConst` for assoc item constraints, array lengths, and const param
defaults.
- Some `ast::AnonConst`s now have their `DefId`s created in
rustc_ast_lowering rather than `DefCollector`. This is because in some
cases they will end up becoming a `ConstArgKind::Path` instead, which
has no `DefId`. We have to solve this in a hacky way where we guess
whether the `AnonConst` could end up as a path const since we can't
know for sure until after name resolution (`N` could refer to a free
const or a nullary struct). If it has no chance as being a const
param, then we create a `DefId` in `DefCollector` -- otherwise we
decide during ast_lowering. This will have to be updated once all path
consts use `ConstArgKind::Path`.
- We explicitly use `ConstArgHasType` for array lengths, rather than
implicitly relying on anon const type feeding -- this is due to the
addition of `ConstArgKind::Path`.
- Some tests have their outputs changed, but the changes are for the
most part minor (including removing duplicate or almost-duplicate
errors). One test now ICEs, but it is for an incomplete, unstable
feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.
### Followup items post-merge
- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
instead (do this in rustc_resolve). Then remove the special-casing from
`rustc_ast_lowering`, so that all params will automatically be lowered as
`ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
trying it in crater
r? `@BoxyUwU`
