Display CPU info in CI
This displays the CPU information on the CI runners in the logs. This can be helpful for diagnosing CI issues and to better understand the environment they are running under.
Fix collision_doc_profile test error
This fixes the `collision_doc_profile` test which was sporadically failing on CI. My theory is that the first `common` build finishes quickly (or the other job slot is delayed). The proc-macro `pm` starts (likely very quickly due to pipelining), and it can jump ahead before the second `common` build starts (or at least before the `Message::Run` message gets delivered).
The order isn't really important or relevant to this test (all that matters is that "common" shows up twice), so this ignores the order of the messages.
cc #11334
fix: Make auto-fix note work with `clippy`
[Someone pointed out](https://github.com/rust-lang/cargo/issues/10976#issuecomment-1307538134) that the suggestion to run `cargo --fix` did not work properly for `cargo clippy`. This makes sure the correct command to run is output when running under `cargo clippy`.
This is done by checking if the `RUSTC_WORKSPACE_WRAPPER` environment variable is set, since `clippy` [sets this every run](51ec465cc3/src/main.rs (L140)). Since other things can use `RUSTC_WORKSPACE_WRAPPER`, we look for a wrapper named [`clippy-driver`](51ec465cc3/src/main.rs (L120)).
Since `clippy` might not be available everywhere `cargo` is tested, this is tested using a `rustc` wrapper.
fix(add): use the possessive in error message
### What does this PR try to resolve?
While using `cargo add` to add some dependencies with features, I noticed this error message didn't use an apostrophe. A really minor issue, but it bugged me 😅
Split up registry documentation into multiple sections
Splits up the documentation for registries into multiple sections. Avoids making any changes to the docs themselves beyond adding links.
The upcoming stabilization of the sparse registry protocol will include more content changes to these docs.
Closes#11476
r? `@ehuss`
Add `home` crate to cargo crates
### What does this PR try to resolve?
The `home` crate is the crate used by both `rustup` and `cargo` to define their home directories. The crate is quite small but plays an important role in gluing rust tooling together. This PR adds this crate the `crates` folder within cargo to allow the cargo team and the rust project to maintain this small crate.
### Additional information
I've also added both `rust-lang-owners` and `ehuss` as owners of the crate. Once, merged I will archive the old repo.
Reference zulip conversation: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Moving.20the.20home.20crate.20into.20rust-lang.20and.20under.20cargo/near/299975263
cc `@weihanglo` `@ehuss`
Allow Check targets needed for optional doc-scraping to fail without killing the build
### What does this PR try to resolve?
In doing a Crater run of -Zrustdoc-scrape-examples, I found that the only remaining regressions are cases where:
* A library does not type-check
* The library has examples
* Cargo tries to scrape the examples, which requires checking the library
* The Check unit for the library fails, crashing the build
The core issue is that the Check unit should be able to fail without killing the build. This PR fixes this issue by checking for this condition, and then allowing the unit to fail.
Specifically, I added a new method `BuildContext::unit_can_fail_for_docscraping` that determines the conditions for whether a unit is allowed to fail. This method is used both in `JobQueue` to interpret process failure, and in the `rustc`/`rustdoc` functions to emit a warning upon failure. I modified `rustc` to handle the case of failure similar to `rustdoc`, but with a slightly different diagnostic.
### How should we test and review this PR?
The unit test `no_fail_bad_lib` has been extended with example files to test this case.
r? `@weihanglo`
fix: gleaning rustdocflags from `target.cfg(…)` is not supported
### What does this PR try to resolve?
Fixes#11310
The bug was `rustflags_from_target` trying to learn rustdocflags from
`target.cfg(…).rustflags`, which is definitely wrong.
As of this writing, either `target.cfg(…).rustdocflags` or
`target.<triple>.rustdocflags` is not supported.
### How should we test and review this PR?
See f8d1b30ad3 as an example.
<!-- homu-ignore:end -->
resolver.md: Fix naming in example
### What does this PR try to resolve?
It fixes what I believe to be a typo in the documentation.
### How should we test and review this PR?
Adding the example as it was to a `Cargo.toml` prints this warning:
```
warning: unused manifest key: dependency
```
With the corrected version it does not.
`{ …, artifact = "bin", target = "target" }` should also be considered
to being built for `FeaturesFor::ArtifactDep` instead of `NormalOrDev`.
[This line][1] requests for `ArtifactDep` but [here][2] Cargo ignore
assumed host target of artifact dep.
Change it to explicit set host target triple when
- `{ …, target = "target" }`, and
- `--target` is not presented, meaning it would be build on host platform.
[1]: 1382b44e43/src/cargo/core/compiler/unit_dependencies.rs (L887)
[2]: 1382b44e43/src/cargo/core/resolver/features.rs (L857)
> Adapted from #11183
Previously, `is_dep_activated` depends on `activated_dependencies`,
which is a map of `PackageFeaturesKey` to its own activated `DepFeature`s.
`PackageFeaturesKey` in feature resolver is always comprised of
* A `PackageId` of a given dependency, and
* A enum value that helps decoupling activated features for that dependency.
Currently depending on the type of given dependency.
Looking into issue 10526, it has an `activated_dependencies` of
```
{
(mycrate, NormalOrDev) -> [dep:mybindep]
}
```
However, this [line][1] accidentally use a parent's `pkgid`
and a dependency's `FeaturesFor` to compose a key:
```
(mycrate, ArtifactDep("x86_64-unknown-linux-gnu"))
```
That is never a valid key to query features for artifacts dependency.
A valid key should be comprised of components both from the parent:
```
(mycrate, NormalOrDev)
```
Or both from the dependency itself:
```
(mybindep, ArtifactDep("x86_64-unknown-linux-gnu"))
```
This `unit_for` is from parent and should already contain its own
artifact dep information inside `artifact_target_for_features`,
so we don't need to map any dependency artifact from `dep.artifact()`.
[1]: a2ea66bea6/src/cargo/core/compiler/unit_dependencies.rs (L1106-L1107)
