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 f8d1b30ad3fe1d5fa0f172031de7c937b235f3ba 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)
Refactor generate_targets into separate module
### What does this PR try to resolve?
The `generate_targets` function is fairly complicated with an absurd number of parameters. This PR refactors the function into a `TargetGenerator` struct that represents the state of the generator, and reduces the amount of parameter-passing between the relevant functions. Additionally, the `generate_targets` function has been refactored into two smaller functions `create_proposals` and `proposals_to_units`. The docscrape-specific functionality from #11430 has been pulled out into a separate function, as promised.
### How should we test and review this PR?
This PR does not change any functionality, so no new tests are added. It should be reviewed for code style.
r? `@weihanglo`
Improve file found in multiple build targets warning
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11248.
Improve file found in multiple build targets warning. This PR tries to print the target name and kind in the warning message.
### How should we test and review this PR?
- [x] Unit Test
Improve strategy for selecting targets to be scraped for examples
### What does this PR try to resolve?
After #10343, we have identified a clear set of conditions for whether a particular target should be considered by `-Zrustdoc-scrape-examples`. These conditions are described more clearly in #11425.
However, after some testing with complex Cargo workspaces (e.g. [wasmtime](https://github.com/bytecodealliance/wasmtime/)), I realized that the current approach of modifying the `CompileFilter` did not correctly implement this new specification. For example, a target with `doc = false` should not be scraped by default since it is not a documented unit, but the current approach would potentially include such a target for scraping.
This PR provides a new approach which I believe correctly implements the specification:
1. `generate_targets` is called with the same parameters except the `mode` which becomes `CompileMode::Docscrape` instead of `CompileMode::Doc`. `filter_default_targets` generates the same targets for `Docscrape` as for `Doc`.
2. Inside `generate_targets`, an initial set of `Proposal`s are created. This set of proposals is extended with further proposals based on targets identified as `doc-scrape-examples = true`, or Example targets where possible.
This PR subsumes #11423, and also fixes#10571.
### How should we test and review this PR?
I have added another test `docscrape::only_scrape_documented_targets` to verify that only documented or explicitly-enabled targets are included for scraping.
r? `@weihanglo`
Add test for rustdoc-map generation when using sparse registries
Fixes#11402.
Adds an explicit check for sparse registries when generating the mappings for `-Zrustdoc-map`, so that the `sparse+` qualifier is removed before the comparison.
Add error message when `cargo fix` on an empty repo
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11380
Add error message when `cargo fix` on an empty repo.
### How should we test and review this PR?
- [x] unit test
```sh
set -eux
cargo +nightly new repro
cd repro
echo "fn main() { let _ = 0.clone(); }" > src/main.rs
cargo fix
```
Store the sparse+ prefix in the SourceId for sparse registries
#11209 added a new `SourceKind::SparseRegistry` and removed the `sparse+` prefix from the URLs stored in the `SourceId`.
The removal of the `sparse+` prefix from the URLs in the `SourceId` has led to several bugs, since registry URLs no longer round-trip through a `SourceId`. The most recent one I found was that the example configuration generated by `cargo vendor` did not include the `sparse+` prefix. Any place that calls the `.url()` method on a `SourceId` potentially has this bug.
This change puts the `sparse+` prefix back in the URL stored in the `SourceId`, but keeps the new `SourceKind::SparseRegistry`.
A test is added for doing `cargo vendor` on an alternative registry using the sparse protocol.
