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 f8d1b30ad3 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)
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 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.
add newline char to `cargo install .` error message for easier reading.
I just noticed the `cargo install .` error message was not formatted very nicely.
Just added a newline char to make it cleaner.
Thanks
Change rustdoc-scrape-examples to be a target-level configuration
This PR addresses issues raised in rust-lang/cargo#9525. Specifically:
1. It enables examples to be scraped from `#[test]` functions, by passing additional flags to Rustdoc to ensure that these functions aren't ignored by rustc.
2. It moves the `arg` from `-Z rustdoc-scrape-examples={arg}` into a target-level configuration that can be added to Cargo.toml.
The added test `scrape_examples_configure_target` shows a concrete example. In short, examples will be default scraped from Example and Lib targets. Then the user can enable or disable scraping like so:
```toml
[lib]
doc-scrape-examples = false
[[test]]
name = "my_test"
doc-scrape-examples = true
```
Add warning when `cargo tree -i <spec>` can not find packages
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11315
Add warning when `cargo tree -i <spec>` can not find packages.
### How should we test and review this PR?
Please run the unit test.
Clean profile, patch, and replace in cargo remove
### What does this PR try to resolve?
This PR is part of the continued work on cargo remove (#11099, see deferred work).
After a successful removal of a dependency, clean up the profile, patch, and replace sections to remove all references to it.
**Note** the GC process was expanded to clean up not just references to the dependencies just removed, but also references of all dependencies. This was because there's not an easy way to determine which dependencies correspond to the given TOML keys, without either 1) figuring that out before the removal (therefore having to predict the behavior), or 2) returning that information from the remove function (somewhat unorthodox for an op).
### How should we review and test this PR?
Verify that the implementation makes sense and that the tests are sufficient.
