Use workspace lockfile when running `cargo package` and `cargo publish`
### What does this PR try to resolve?
Fix#11148.
### How should we test and review this PR?
Please run the integration test in `tests/testsuite/publish_lockfile.rs` or try the steps from the issue.
Fix examples of proc-macro crates being scraped for examples
This PR fixes#11496, where examples in proc-macro crates would crash the build with `-Zrustdoc-scrape-examples`. The fix is to change `unit_needs_doc_scrape` to check if a unit is coming from a `proc-macro` package. I added a test to ensure the simple example passes. I also ensured that [automod](https://github.com/dtolnay/automod) also documents correctly.
r? `@weihanglo`
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 -->
