Add more options to registry test support.
This adds a few things that are missing in the registry test support code. These aren't immediately necessary, since no tests rely on them. However, I wrote it for something else that I ended up not needing, but I think it is still helpful for future work.
The additions are:
- Ability to specify `default-features=false` for a registry dependency.
- Include binary dependencies in the index for the `cargo publish` HTTTP server (current `cargo publish` tests use `file:///` upload, and don't verify the index).
- Include `rust-version` in the `cargo publish` HTTP server (current `cargo publish` tests don't verify the index).
- Include the `features=[…]` field for dependencies in the published `Cargo.toml` (cargo doesn't read features from `Cargo.toml`, it only uses the registry, but it is probably best to keep it in sync).
- Include the `package="…"` field for dependencies (for renamed dependencies) in the published `Cargo.toml` (similarly, cargo only uses the index, but it is probably good to keep in sync).
Don't filter on workspace members when scraping doc examples
Fixes https://github.com/rust-lang/cargo/issues/13074.
I confirmed locally that it fixed the issue in docs.rs.
cc `@willcrichton`
r? `@epage`
fix(resolver): Remove unused public-deps error handling
To implement rust-lang/rfcs#3516, we need to decouple the resolver's behavior from the unstable flag. Since the code path is now dead, I went ahead and removed it.
Fixes error count display is different when there's only one error left
### What does this PR try to resolve?
When there's only 1 error left, the number 1 appears in the output so that it scans the same as the output when there's more than 1 error, so:
```
error: could not compile `crate` (lib test) due to 1 previous error
```
instead of the current:
```
error: could not compile `crate` (lib test) due to a previous error
```
Fixes#12390
rustc related PR [#114759](https://github.com/rust-lang/rust/pull/114759)
fix: reorder `--remap-path-prefix` flags for `-Zbuild-std`
### What does this PR try to resolve?
Order of `--remap-path-prefix` flags is important for `-Zbuild-std`.
We want to show `/rustc/<hash>/library/std` instead of `std-0.0.0`.
Fixesrust-lang/rust#117839
### How should we test and review this PR?
Follow the steps in rust-lang/rust#117839, or run
```
CARGO_RUN_BUILD_STD_TESTS=true cargo +nightly t --test build-std
```
to verify.
docs: remove review capacity notice in PR template
Forgot to update PR template in #12842. This updates accordingly.
Note that this doesn't mean Cargo start accepting arbitrary pull requests or features. The reviewers are still a small handful of people. The guideline never changes — issue, discuss, then pull request.
fix(resolver): De-prioritize no-rust-version in MSRV resolver
### What does this PR try to resolve?
This is a corner case without a good answer.
As such, this change leans on some happy-path entries existing and
preferring those.
### How should we test and review this PR?
### Additional information
This was originally discussed around the time of #12950 but was held off.
When working on this, I was considering other heuristics like
- If a future version has an MSRV, assume that it applies also to the current version
- This can be added in the future
- We likely would want to consider an alternative value, like inferring the rust-version from the manifest or the rust-version used from publish
- Sort no-MSRV versions of a package by minimal versions
- The lower the version, the more likely it is to be compatible
- This likely could apply to incompatible MSRVs (or we could reverse-sort those by rust-version) but those will error anyways without `--ignore-rust-version`, so I decided against these
- I realized this was a backdoor to minimal versions for dependencies without a MSRV and that the community support isn't there for that yet to be a high enough quality of an experience
docs: link to the packages lint table from the related workspace table
### What does this PR try to resolve?
This PR makes the exact format and definition of the workspace `lints` table easier to discover. It also follows the style of the surrounding documentation, such as the section immediately before about the `dependencies` table, which cross-references related package table documentation.
### How should we test and review this PR?
N/A
### Additional information
N/A
docs: Provide pointers for MSRV
### What does this PR try to resolve?
In today's cargo team meeting, we discussed the Pre-RFC for MSRV-aware resolver for #9930.
In that discussion, the question of recommending a policy came up. While we didn't feel the ecosystem has coalesced enough to set one (and we hope MSRV-aware resolver will avoid the need),
it became clear that some we can provide some basic help to the user, including
- Raising awareness of tools to find the actual MSRV
- The policy that they should verify it with examples on how to do so
### How should we test and review this PR?
While this recommends some specific third-party tools, I'm not aware of other tools within this for us to worry about at this time for us to create any guidelines on which we should include.
Explanations are given for the example CI job to discourage cargo culting and instead give people the information they need in making decisions relevant to their project.
### Additional information
I'd love to provide information to help users create their own MSRV policy but only if there was an automated way of collecting and reporting some of the data, like crates.io providing a dashboard of MSRVs set or rust-versions inferred from user-agents.
Without that, I felt it not worth getting into other policy discussions like reactive vs proactive updating of MSRV, automated MSRV updates, etc. These can always be added later.
This also helps towards #5656.
This makes the exact format and definition of the workspace `lints`
table easier to discover. It also follows the style of the surrounding
documentation, such as the section immediately before about the
`dependencies` table, which cross-references related package table
documentation.
In today's cargo team meeting, we discussed the Pre-RFC for MSRV-aware
resolver.
In that discussion, the question of recommending a policy came up.
While we didn't feel the ecosystem has coalesced enough to set one (and
we hope MSRV-aware resolver will avoid the need),
it became clear that some we can provide some basic help to the user,
including
- Raising awareness of tools to find the actual MSRV
- The policy that they should verify it with examples on how to do so
While this recommends some specific third-party tools,
I'm not aware of other tools within this for us to worry about at this
time for us to create any guidelines on which we should include.
review and remove ignored tests in rustfix
### What does this PR try to resolve?
review ignored tests in rustfix crate per #13034.
### How should we test and review this PR?
CI testing
### Additional information
* Removed unproductive test in `parse_and_replace`
* un-ignore proptests, and reduce runtime from ~2s to ~<.25s
feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable)
### What does this PR try to resolve?
This is an alternative to #12158's `CARGO_WORKSPACE_DIR` that was
implementing the solution to #3946 that previously discussed in the
cargo team meeting.
`CARGO_WORKSPACE_DIR` is a bit awkward to document / describe because
its the effective workspace directory of the thing being built.
If the thing being built doesn't have a workspace, it falls back to
`CARGO_MANIFEST_DIR`.
It would also be hard to take into account what the
`CARGO_WORKSPACE_DIR` would be for path dependencies into foreign
workspaces *and* it wouldn't solve the problem the user is having.
What the user really wants is the CWD of rustc when it is invoked.
This is much simpler to describe and is accurate when using a path
dependency to a foreign package.
Because the CWD is a much simpler mechanism to talk about, I figured we
could diverge from our prior consensus and make it always present,
rather than limiting it to tests.
### How should we test and review this PR?
The preparatory refactor commits have explanation for why they were to help
### Additional information
Remaining work for #3946: get this stabilized
Exited with hard error when custom build file no existence or not in package
## What does this PR try to resolve?
Fixed https://github.com/rust-lang/cargo/issues/11383
## How should we test and review this PR?
Add test `build_script_outside_pkg_root`, this will check `custom_build.rs` existence and whether in the package root, if not then exited with a hard error
## Additional information
The code just handle the `custom build` target that i know how to test it. Other target type is skipped.
try running on windows
### What does this PR try to resolve?
Try getting rustfix tests to run on windows and fix#13033
### How should we test and review this PR?
CI should catch failure. Look out for flaky tests in the long run.
### Additional information
tested briefly on win11.
To implement rust-lang/rfcs#3516, we need to decouple the resolver's
behavior from the unstable flag. Since the code path is now dead, I
went ahead and removed it.
refactor(toml): Better abstract inheritance details
There is no reason that the caller for inheriting needs to know the details of the inner types doing inheritance.
