rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
Lintcheck maintenance
Make `cargo lintcheck -j 0` use all threads instead of panicking, and cleanup (and shorten) lintcheck's parsing code.
changelog: none
This makes the code shorter and clearer.
The only incompatible change is that an explicit command-line argument
`--crates-toml=` will take precedence over the `LINTCHECK_TOML`
environment variable.
Using `rayon::current_num_threads()` causes a bug:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
ThreadPoolBuildError { kind: GlobalPoolAlreadyInitialized }',
src/main.rs:632:10
```
Moreover, using the number of threads and dividing it by 2 wouldn't
return the number of physical threads on modern processors which have
a varying number of threads per core.
It makes little sense to restrict ourselves to physical threads,
especially when, in modern architectures, cores with multiple threads
are often faster (performance) while cores with a unique threads are
often slower (efficient). The Rust runtime will make a better choice.
Downgrade let_underscore_untyped to restriction
From reading #6842 I am not convinced of the cost/benefit of this lint even as a pedantic lint.
It sounds like the primary motivation was to catch cases of `fn() -> Result` being changed to `async fn() -> Result`. If the original Result was ignored by a `let _`, then the compiler wouldn't guide you to add `.await`. **However, this situation is caught in a more specific way by [let_underscore_future](https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_future) which was introduced _after_ the original suggestion (#9760).**
In #10410 it was mentioned twice that a <kbd>restriction</kbd> lint might be more appropriate for let_underscore_untyped.
changelog: Moved [`let_underscore_untyped`] to restriction
Restrict `#[rustc_box]` to `Box::new` calls
Currently, `#[rustc_box]` can be applied to any call expression with a single argument. This PR only allows it to be applied to calls to `Box::new`
Update version attribute for 1.68 lints
Roses are red,
violets are blue,
I'm running out of rhymes,
changelogs are crimes????
---
changelog: none
<!-- changelog_checked -->
Two small documentation improvements
The `wrong_self_convention` changes are for grammar and accuracy.
The `must_use_candidate` change is because that lint flags only exported functions: 8b65632b6e/clippy_lints/src/functions/must_use.rs (L27-L31)
changelog: `wrong_self_convention` and `must_use_candidate` documentation improvements
Scope `missing_docs_in_private_items` to only private items
`missing_docs_in_private_items` currently detects missing docs for public items as well as private. Since `missing_docs`already covers public items, this PR updates `missing_docs_in_private_items` to only cover private items.
Fixes#1895
changelog: [`missing_docs_in_private_items`]: Apply lint only to private items (used to be public and private)
Run dogfood to completion
Run dogfood on all packages before failing the test. Failing early is painful on lints which trigger on multiple crates.
changelog: None
Fix ICE in `multiple_unsafe_ops_per_block`
fixes#10367
changelog: [`multiple_unsafe_ops_per_block`]: Fix ICE when calling a function-like object in an unsafe block
Fix array-size-threshold config deserialization error
changelog: Fix error when providing an `array-size-threshold` in `clippy.toml`
Not entirely sure why it doesn't want to deserialize a u128, but converting it after the fact is an easy enough fix
Fixes#10422
Do not suggest to derive `Default` on generics with implicit arguments
Fixes#10396
changelog: FP: [`derivable_impls`]: do not suggest to derive `Default` on generics with implicit arguments
Remove `from` lang item
It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
