Fix use of .. in dep-info-basedir
### Summary
This allows setting, in .cargo/config's dep-info-basedir, some relative path that goes above the crate's directory.
### Motivation
In a setup like this:
```
repo_root
├── Makefile
├── some_c_things
│ └── foo.c
└── rust_things
├── Cargo.toml
└─── src
└── lib.rs
```
If you want the generated .d files to be includable directly in the Makefile (without post-processing), you need them to mention paths relative to the root, like:
rust_things/target/....: rust_things/src/lib.rs
### Implementation
For this you need to have relative paths with parent directories (in this case ..) in dep-info-basedir, which does not work without the change in this PR (due to render_filename doing only strip_prefix, while the basedir still contains literal ..s).
Let me know if this change is acceptable. Another implementation could be to canonicalize in ConfigRelativePath::resolve_path instead, especially since that struct outputs absolute paths. But that would have it access the filesystem, while it currently doesn't.
Move snapshot tests into testsuite
This moves all tests from the `snapshot` folder into the `testsuite` folder as described by [this comment](https://github.com/rust-lang/cargo/pull/10631#discussion_r866306441). A macro was also added so there is no need to specify the path in a `snapshot` test just the file. This was done for ease of refactoring and ease of porting new tests to `snapshot`
close#10627
r? `@epage`
Improve support of condition compilation checking
This PR is a series of improvements to the check-cfg implementation.
### What does this PR try to resolve?
This PR resolve the concern expressed in https://github.com/rust-lang/cargo/pull/10486#issuecomment-1096842314 that is:
* Fixing the tests on Windows: e8aa51d8de
* Merging all the -Z flags under -Zcheck-cfg: 969e282b8f
* Moving of all of the check-cfg tests into a separate module: c18b442b30
* And removing of an unused parameter: 068bdf4c06
### How should we test and review this PR?
This PR should be reviewed commit by commit and tested with the automated tests or examples.
### Additional information
I decided to use a custom macro to make the test functional under Windows, the macro generate a contains line with the correct escaping depending on the platform (windows or not windows).
When documenting private items in a binary, ignore warnings about links to private items
Previously, rustdoc would warn about linking to private items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
Fixes https://github.com/rust-lang/rust/issues/89600.
Extend pkgid syntax with `@` support
In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We
are also making it the default way of rendering pkgid's for the user.
### What does this PR try to resolve?
With cargo-add in #10472, we've decided to only use ``@`` in it and to add
it as an alternative to `:` in the rest of cargo. `cargo-add`
originally used ``@`.` When preparing it for merge, I switched to `:` to
be consistent with pkgids. When discussing this, it was felt ``@`` has
precedence in too many tools to switch to `:` but that we should instead
switch pkgid's to use ``@`,` in a backwards compatible way. #10472 served
as the change proposal for this
See also
- https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Multiple.20ways.20of.20specifying.20versions
### How should we test and review this PR?
The focus of the testing is on the parsers unit tests and on the end-to-end output. We are not explicitly testing end-to-end input in this PR, assuming the unit tests are sufficient.
### Additional information
This only focuses on places we already accept pkgids. Looking into supporting `foo@1.2.3` in `cargo install` and `cargo yank` is being left for a future PR.
move one `snapshot/add` test into `testsuite/cargo_add/`
This is an experiment with moving the test code related to a snapshot into the testsuite directory so it's easier to review.
- To kick the tire on these changes, a single test was ported
This is a step towards #10627. A follow up will port all of the tests
r? `@epage`
Add caveat for covering features
This section explains the caveats and possible solutions for features, detailing the tooling needed to 100% cover such a project.
The need for this PR is based on a conversation with `@Eh2406.`
Moved this PR here based on `@Eh2406's` comment: https://github.com/rust-lang/reference/pull/1195#issuecomment-1108968173
Improve CARGO_ENCODED_RUSTFLAGS and CARGO_ENCODED_RUSTDOCFLAGS variables docs
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/10555
It has been improved according to the three requirements in the issue.
reorganize `snapshot` tests to better work in contexts that sort by extension
Changed snapshot file stricture from
```
<name>.in/
<name>.out/
<name>.stdout
<name>.stderr
```
To
```
<name>/in/
<name>/out/
<name>/stdout.log
<name>/stderr.log
```
This makes it easier to review and make changes when in contexts that sort by extension
close#10626
r? `@epage`
Add support for `-Zbuild-std` to `cargo fetch`
This allows downloading the dependencies for libstd in advance, which
can be useful in e.g. sandboxed build environments.
Fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/22.
r? `@ehuss`
This allows downloading the dependencies for libstd in advance, which
can be useful in e.g. sandboxed build environments.
- Abstract check for `--target` out into a function
- Try to abstract `test` special-casing into a function
This avoids hard-coding crate names in multiple places.
- Unify handling of checks for `--target` in `BuildConfig::new`
This makes sure it's checked consistently, without requiring each new command to check it explicitly.
- Share more code between `fetch` and `build` by adding `std_crates()`
- Warn about `--build-plan` and `-Zbuild-std` consistently, not just for `build`
Currently only `build` uses build-plan. But cargo may choose to add it to new commands in the future (e.g. check and doc).
Future-proof it, since it's simple to do.
Previously, rustdoc would warn about linking to items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
Migrate tests of `cargo-init` to snapbox
### What does this PR try to resolve?
An attempt of migrating tests of `cargo-init` to [snapbox](https://crates.io/crates/snapbox/).
### How should we test and review this PR?
To review this PR, you may compare the old and the new version one by one. Files not listed in `<test-name>.out` are not asserted, so please help me make sure we don't miss any essential file to check.
Some redundant tests are covered by other tests or renamed.
### Additional information
I won't say the process of the migration was pleasant, but overall it results to a higher coverage of output file changes. Here are steps I performed to migrate a test case:
1. Run the old test and observe its output layout. Recommend using a separate worktree to preserve the temporary test output files.
2. Read the test code to arrange its input fixture at `<test-name>.in`.
3. Copy the old output layout or hand-pick the output layout you need. You don't need to fill contents of those files. `snapbox` will do it for you.
4. Run `SNAPSHOTS=overwrite cargo test --test testsuite <your-test-filter>` to assert and generate snapshots.
5. Compare the old layout and the new layout to see if anything missing.
Something observations when dealing with the migration:
* snapbox hasn't yet support unordered assertion.
* snapbox cannot assert inexistence of a file (And probably never?).
* No performance hit so far (measured with hyperfine).
Update GitHub Actions actions/checkout@v2 to v3
The v2 implementation uses Node 12, which is end-of-life on April 30, 2022. See https://nodejs.org/en/about/releases/. Update to v3, which is based on Node 16 whose support lasts until April 30, 2024.
They made this a major version change (v2 to v3) because old GitHub Enterprise versions aren't necessarily compatible with Node 16, but for github.com-supplied runners (SaaS) there is no practical difference.
The v2 implementation uses Node 12, which is end-of-life on April 30, 2022.
See https://nodejs.org/en/about/releases/. Update to v3, which is based on
Node 16 whose support lasts until April 30, 2024.
Integrate snapbox in with cargo-test-support
### What does this PR try to resolve?
#10472 introduced snapbox to cargo's tests in the least intrusive manner by copying some cargo-test-support code. Primarily, this PR works to de-duplicate that code. Secondarily, it makes it possible for snapbox to be used by other cargo tests that can work with its more limited functionality compared to cargo-test-support.
### How should we test and review this PR?
This is broken down by commits for smaller chunks to look over with some extra details in some of the commit messages.
As this is effectively refactoring existing tests, them passing is sufficient for testing. The main focus would be on any API design including if there are any practices that we used to do that this continues forward to snapbox that we shouldn't.
### Additional information
The cargo contributing guide also needs to be updated but I'm leaving that off for another PR once this is merged so we have a clearer idea of what the API will look like (less churn) and so we can focus the conversation for each PR.
Update documentation for workspace inheritance
Tracking issue: #8415
RFC: rust-lang/rfcs#2906
This updates documentation about workspace inheritance in the Cargo Book. This is meant to move the documentation into a state that is acceptable to move after stabilization. It currently proposes adding sections to `workspaces.md` and `specifying-dependencies.md`.
r? `@epage`
move workspace inheritance untable docs to the correct place
Workspace inheritance unstable docs were under `Stabilized and removed features`. This moves them to the correct location
r? `@epage`
