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
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.
Causes cargo to re-run clippy when those paths are modified
Also tracks the path to `clippy-driver` in debug mode to remove the
workarounds in `cargo dev lint` and `lintcheck`
This has been unstable since it was first introduced in
https://github.com/rust-lang/rust-clippy/pull/5363. In that time, I have
been using it successfully in nightly without issues. I don't think
there are any blocking issues now that RUSTC_WORKSPACE_WRAPPER is
stabilized, so this can be stabilized.
This will terminate the program if run via "cargo run".
"cargo run" does currently not work because at least a bunch of paths do not take that into account.
