collapsible_match: fix lint message capitalization
(see https://rustc-dev-guide.rust-lang.org/diagnostics.html for details)
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: collapsible_match: fix lint message capitalization
lintcheck: parallelize
By default we use a single thread and one target dir as before.
If `-j n` is passed, use `n` target dirs and run one clippy in each of them.
We need several target dirs because cargo would lock them for a single process otherwise which would prevent the parallelism.
`-j 0` makes rayon use $thread_count/2 (which I assume is the number of physical cores of a machine) for the number of threads.
Other change:
Show output of clippy being compiled when building it for lintcheck (makes it easier to spot compiler errors etc)
Show some progress indication in the "Linting... foo 1.2.3" message.
Sort crates before linting (previously crates would be split randomly between target dirs, with the sorting, we try to make sure that even crates land in target dir 0 and odd ones in target dir 1 etc..)
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: parallelize lintcheck with rayon
Make `Clean` take &mut DocContext
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
This combined with https://github.com/rust-lang/rust/pull/82018 should hopefully help with https://github.com/rust-lang/rust/pull/82014 by allowing `cx.cache.exported_traits` to be modified in `register_res`. Previously it had to use interior mutability, which required either adding a RefCell to `cache.exported_traits` on *top* of the existing `RefCell<Cache>` or mixing reads and writes between `cx.exported_traits` and `cx.cache.exported_traits`. I don't currently have that working but I expect it to be reasonably easy to add after this.
It should be never break another crate to re-export a public item.
Note that this doesn't check the feature gate at
*all* for other crates:
- Feature-gates aren't currently serialized, so the only way to check
the gate is with ad-hoc attribute checking.
- Checking the feature gate twice (once when documenting the original
crate and one when documenting the current crate) seems not great.
This should still catch using the feature most of the time though, since
people tend to document their own crates.
