Support vendoring with different revs from same git repo
### What does this PR try to resolve?
Fixes#10667
### How should we test and review this PR?
test case is included
fix: deduplicate dependencies by artifact target
### What does this PR try to resolve?
In cases when a compile target is specified for a bindep and the crate depending on it, cargo fails to deduplicate the crate dependencies and attempts to build the dependent crate only once with non-deterministic feature set, which breaks e.g. https://github.com/rvolosatovs/musl-bindep-feature-bug
Fix the issue by including the optional artifact compile target in the `Unit` in order to avoid wrongfully deduplicating the dependent crates
Fixes https://github.com/rust-lang/cargo/issues/11463
Fixes https://github.com/rust-lang/cargo/issues/10837
Fixes https://github.com/rust-lang/cargo/issues/10525
Note, that this issue is already accounted for by `cargo`, but in different context a similar situation can occur while building the build script, which:
1. may be built for different target than the actual package target
2. may contain dependencies with different feature sets than the same dependencies in the dependency graph of the package itself
That's why this PR is simply reusing the existing functionality for deduplication
### How should we test and review this PR?
Build https://github.com/rvolosatovs/musl-bindep-feature-bug
### Additional information
This is based on analysis by `@weihanglo` in https://github.com/rust-lang/cargo/issues/10837#issuecomment-1339365374
I experimented with adding the whole `UnitFor` to the internal unit struct, but that seems unnecessary.
It would probably be nicer to refactor `IsArtifact` and instead turn it into a 3-variant enum with a possible compile target, but I decided against that to minimize the diff. Perhaps it's worth a follow-up?
Add warning if potentially-scrapable examples are skipped due to dev-dependencies
### What does this PR try to resolve?
Another point of feedback I've received on the scrape-examples feature is that the dev-dependency situation is quite confusing and subtle. To make users more aware of the issue, I added a warning where Cargo will alert users when examples are skipped due to a dev-dependency requirement, along with proposing a fix.
### How should we test and review this PR?
The test `docscrape::no_scrape_with_dev_deps` has been updated to reflect this new warning.
r? `@weihanglo`
(PS thank you for the reviews Weihang. I know I'm doing lots of little patches right now to get this feature finalized. If you want to share the reviewing burden on scrape-examples with anyone else, let me know!)
Don't scrape examples from library targets by default
### What does this PR try to resolve?
Based on some [early feedback](https://www.reddit.com/r/rust/comments/zosle6/feedback_requested_rustdocs_scraped_examples/) about the scrape-examples feature, both documentation authors and consumers did not consider examples useful if they are scraped from a library's internals, at least in the common case. Therefore this PR changes the default behavior of `-Zrustdoc-scrape-examples` to *only* scrape from example targets, although library targets can still be configured for scraping.
### How should we test and review this PR?
I have updated the `docscrape` tests to reflect this new policy, as well as the Unstable Options page in the Cargo book.
r? `@weihanglo`
Stabilize terminal-width
This stabilized the passing of the `--diagnostic-width` flag to rustc and rustdoc so that they will format diagnostics to fit within the terminal size. Previously they always assume the width is 140. The diagnostics are trimmed with `...` to elide parts of extra-long lines.
In cases where the width isn't known (such as not when used on a tty, or with mintty), then cargo does not pass the flag and the default of 140 is still used.
At this time there is no way for the user to override the width (unlike with the progress bar width). That can be added in the future if there is demand. https://github.com/rust-lang/rust/issues/84673#issuecomment-1179096971 contains some thoughts on some different ideas.
Closes https://github.com/rust-lang/rust/issues/84673
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.
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 -->
`{ …, 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)
