fix bugs with `workspace` key and `update_toml`
### Motivations and Context
When working on an external subcommand to help with the switch to workspace inheritance, I found issues with the output `Cargo.toml` it was creating. When a `cargo_add::Dependency` would change its source to a `WorkspsaceSource`, `workspace = true` would not show up. This lead me to discover that the `default-features` key was not being removed when the `workspace` key was set.
This fixes those issues but brought up questions about how to deal with removing keys and clearing conflicting fields in a `Dependency`. After talking with `@epage,` it was decided that this was the minimal set of changes to make while the changes to fix the other issues is workshopped.
### Changes
- add `default-features` to the list of keys to remove when the source is a `WorkspaceSource`
- insert a `workspace` key when the source is a `WorkspaceSource`
Add unstable `rustc-check-cfg` build script output
This PR adds a new build script output as unstable behind `-Zcheck-cfg=output`: `rustc-check-cfg`.
### What does this PR try to resolve?
This PR add a way to add to use the unstable `--check-cfg` command line option of `rustc` and `rustdoc`.
It was discover in [Bump bootstrap compiler to 1.61.0 beta](https://github.com/rust-lang/rust/pull/95678#discussion_r842803445) that `rustc_llvm` sets some custom `cfg` from a build script and because `--check-cfg=values()` is globally enable in the Rust codebase that cause the compilation to fail. For now no values are checked in stage 0 for the entire codebase which is a shame and should be fixed with the addition of this feature.
### How should we test and review this PR?
Commits are separated in: implementation, tests and doc.
Testing should simply be done by adding a valid `cargo:rustc-check-cfg` in a build script.
Watch the added tests or doc to have an example.
### Additional information
This PR is also the logical next step after `-Zcheck-cfg-features`.
pre-stabilization documentation for workspace inheritance
This is adding documentation for how we would like users to test workspace inheritance.
This came about from a discussion between `@epage` and I on better ways to document "pre-stabilization" features that are looking for people to test them. One of the ideas was to add some of the documentation to `unstable.md` so that it is all in one area. Having it in one area allows us to link to it so there are testing notes and documentation in one place. It also helps when posting in various places looking for testers as we can link to the nightly docs as needed. One idea was to post in TWiR [under a new table](https://github.com/rust-lang/this-week-in-rust/issues/3236) and this also helps with this.
The new documentation covers
- What we are looking for from testers
- Where to give feedback
- How to test this feature
- An example port as a guide
r? `@epage`
test: Make curr_dir work in/out of workspace
### What does this PR try to resolve?
Get snapbox tests passing when testing `cargo` as part of the `rust-lang/rust` workspace via a git submodule.
- When running tests in the `rust-lang/cargo` repo, `file!` is relative to
the crate root and tests are run relative to the crate root and
everything is fine.
- When running tests in the `rust-lang/rust` repo, `file!` is relative to
the workspace root and tests are run relative to the crate root and
there is much sadness.
If we are compiling relative to the crate root, we could make the path
absolute and everything would be dandy but this needs to happen at
compile time. Didn't see a way to do this.
We could stop using `curr_dir` but that makes the tests a bit noisier
with more overhead for creating a new tests from an existing case.
Since we can reasonly know what all roots will be used for `file!`, we
can just hard code-in support for those two roots. Much happiness
ensues as everything works with this surgical hack.
### How should we test and review this PR?
I ran the tests in both the `cargo` and `rust` repos. You can as well.
### Additional information
When running tests in the `rust-lang/cargo` repo, `file!` is relative to
the crate root and tests are run relative to the crate root and
everything is fine.
When running tests in the `rust-lang/rust` repo, `file!` is relative to
the workspace root and tests are run relative to the crate root and
there is much sadness.
If we are compiling relative to the crate root, we could make the path
absolute and everything would be dandy but this needs to happen at
compile time. Didn't see a way to do this.
We could stop using `curr_dir` but that makes the tests a bit noisier
with more overhead for creating a new tests from an existing case.
Since we can reasonly know what all roots will be used for `file!`, we
can just hard code-in support for those two roots. Much happiness
ensues as everything works with this surgical hack.
Fix no_cross_doctests race condition.
The change in #10594 to the `no_cross_doctests` test introduced a race condition. The two `rustc` invocations happen concurrently, which means the order is not deterministic. This adds`_unordered` along with differentiating text to fix the issue.
feat(install): Support `foo@version` like cargo-add
### What does this PR try to resolve?
This aims to make `cargo install` consistent with
- `cargo add foo@version` from #10472
- pkgid changes in #10582
- `cargo yank foo@version` from #10597
It also offers a shorthand for people installing a specific version.
### How should we test and review this PR?
#10582 acted as the FCP for this, see #10597
Documentation updates are split into their own commit to not clog up browsing the code.
Examine the tests to see if they make sense
### Additional information
While the `foo@vewrsion` syntax is the same, each's semantics are different. We had decided it was better to have the same syntax with different semantics than having the user worry about what syntax they use where. In `cargo install`s case, it has an
implicit-but-required `=` operand while `cargo-add` allows any operand.
This doesn't use the full `pkgid` syntax because that allows syntax that
is unsupported here.
This doesn't use `cargo-add`s parser because that is for version reqs.
I held off on reusing the parser from `cargo-yank` because they had
different type system needs and the level of duplication didn't seem
worth it (see Rule of Three).
fix typos found by the `typos-cli` crate
This fixes various typos inside `cargo`. They were found by [`typos-cli`](https://crates.io/crates/typos-cli). A few different typos were left out as they seemed either intentional or were needed. Typos found in `LICENSE-THIRD-PARTY` were left alone as well.
r? `@epage`
feat(yank): Support foo@version like cargo-add
### What does this PR try to resolve?
In #10472, cargo-add was merged with support for an inline version
syntax of `cargo add foo@version`. That also served as the change proposal for
extending that syntax to `cargo yank` for convenience and consistency.
### How should we test and review this PR?
Documentation updates are split into their own commit to not clog up browsing the code.
The ops API is generic enough that this is implemented purely in the command.
For now, the `foo@version` syntax parser is being left in the command, rather than being shared, as we see how the behavior of these different parsers diverge for their target needs to see what makes sense for refactoring. See also The Rule of Three
- This doesn't use the full `pkgid` syntax (modified in #10582) because that allows syntax that is unsupported here.
- This doesn't use `cargo-add`s parser because that is for version reqs.
Tests were added for various combinations of flags and behavior.
### Additional information
The major difference is that `cargo-add` is specifying a version-req
while `cargo-yank` is specifying a version. This was originally discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Multiple.20ways.20of.20specifying.20versions) and there seemed to be a desire to have one syntax rather than the user thinking about a syntax per type of version (which users won't always think about). See also #10582 which extended the pkgid spec syntax and has some more discussion on this general trend.
`cargo-install` will be updated in a subsequent PR.
add `cargo-features` to unstable docs for workspace inheritance
The unstable docs for workspace inheritance did not include `cargo-features = ["workspace-inheritance"]`. If a user were to follow the docs cargo would throw an error saying to `feature `workspace-inheritance` is required`. It would be better to explicitly add this to the unstable docs and remove it during stabilization.
r? `@epage`
