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
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).
Inlining format args prevents accidental `&` misuse.
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`
