fix ice reporting in lintcheck
Fixes https://github.com/rust-lang/rust-clippy/issues/12185
This PR fixes the lack of reported ICEs within lintcheck by modifying the way in which data is collected from each crate being linted.
Instead of lintcheck only reading `stdout` for warnings, it now also reads `stderr` for any potential ICE (although admittedly, it is not the cleanest method of doing so). If it is detected, it parses the ICE into its message and backtrace separately, and then adds them to the list of outputs via clippy.
Once all outputs are collected, the formatter then proceeds to generate the file as normal.
Note that this PR also has a couple of side effects:
- When clippy fails to process a package, but said failure is not an ICE, the `stderr` will be sent to the console;
- Instead of `ClippyWarning` being the primary struct for everything reported, there is now `ClippyCheckOutput`, an enum which splits the outputs into warnings and ICEs.
changelog: none
Document that `cargo clippy --fix` implies `--all-targets`
In [`cargo fix`'s documentation](https://doc.rust-lang.org/cargo/commands/cargo-fix.html) they indicate that `fix` implies `--all-targets` if no target is supplied. As Clippy uses Cargo under the hood, this also applies to Clippy, but we didn't document that behaviour.
This PR changes that
Fixes#10690
changelog: Add to documentation that `--fix` implies `--all-targets`
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.