bors [Mon, 23 May 2022 16:50:11 +0000 (16:50 +0000)]
Auto merge of #10696 - ehuss:update-curl, r=epage
Update libcurl
This updates to the latest libcurl.
Changes in curl:
* 0.4.42: https://github.com/alexcrichton/curl-rust/releases/tag/0.4.42
* 0.4.43: https://github.com/alexcrichton/curl-rust/releases/tag/0.4.43
Changes in libcurl:
* From 7.80.0 to 7.83.1: https://curl.se/changes.html
There were several security issues addressed recently (https://curl.se/docs/security.html), however, I don't think any of them are particularly concerning for us.
bors [Fri, 20 May 2022 22:41:12 +0000 (22:41 +0000)]
Auto merge of #10685 - Muscraft:cargo-add-workspace-source, r=epage
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`
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`.
bors [Wed, 18 May 2022 01:52:07 +0000 (01:52 +0000)]
Auto merge of #10675 - Muscraft:update-contrib-docs, r=weihanglo
Add notes about pre-stabilization to contributor unstable docs
This PR is meant to add more direction for contributors on the path to stabilization for unstable features. It adds a section titled `Pre-Stabilization` to the unstable contributor docs.
The idea for this [came out of the discussion](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/workspace.20inheritance.20stabilization/near/281856280) about when and how to stabilize workspace inheritance. The notes that are being added were derived from the above comment as well as the [the adding of the `Call for Testing`](https://github.com/rust-lang/this-week-in-rust/issues/3236) section to TWiR. [This comment](https://github.com/rust-lang/this-week-in-rust/pull/3260#discussion_r874977470) gives more information as well.
As for the requirement of testing notes, [there is still discussion about if they are needed](https://github.com/rust-lang/this-week-in-rust/pull/3260#discussion_r874985133).
While what was added is not comprehensive it is meant as a guide for what to do as each feature has different requirements for stabilization
bors [Tue, 17 May 2022 15:20:10 +0000 (15:20 +0000)]
Auto merge of #10674 - petrochenkov:linklib, r=ehuss
reference: Update syntax supported by `rustc-link-lib`
This doc already contains a link below pointing to the relevant rustc documentation https://doc.rust-lang.org/nightly/rustc/command-line-arguments.html#-l-link-the-generated-crate-to-a-native-library which has the updated syntax.
bors [Thu, 12 May 2022 15:19:04 +0000 (15:19 +0000)]
Auto merge of #10659 - Muscraft:prestabilization-inheritance-docs, r=epage
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
bors [Thu, 12 May 2022 14:00:45 +0000 (14:00 +0000)]
Auto merge of #10658 - epage:fix, r=ehuss
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.
Ed Page [Wed, 11 May 2022 15:30:41 +0000 (10:30 -0500)]
test: Make curr_dir work in/out of workspace
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.
bors [Wed, 11 May 2022 23:10:18 +0000 (23:10 +0000)]
Auto merge of #10660 - ehuss:fix-no_cross_doctests-race, r=weihanglo
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.
bors [Wed, 11 May 2022 03:25:36 +0000 (03:25 +0000)]
Auto merge of #10650 - epage:install, r=ehuss
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).
bors [Tue, 10 May 2022 23:58:15 +0000 (23:58 +0000)]
Auto merge of #10649 - Muscraft:fix-typos, r=epage
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.
bors [Tue, 10 May 2022 21:53:54 +0000 (21:53 +0000)]
Auto merge of #10597 - epage:yank, r=ehuss
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.
bors [Tue, 10 May 2022 19:34:45 +0000 (19:34 +0000)]
Auto merge of #10648 - Muscraft:update-workspace-inheritance-docs, r=epage
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.
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.
bors [Sat, 7 May 2022 02:14:00 +0000 (02:14 +0000)]
Auto merge of #10638 - Muscraft:move-snapshot-tests, r=epage
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`
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).
bors [Fri, 6 May 2022 19:48:59 +0000 (19:48 +0000)]
Auto merge of #10142 - jyn514:bin-private-link, r=ehuss
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.
bors [Fri, 6 May 2022 19:07:07 +0000 (19:07 +0000)]
Auto merge of #10582 - epage:pkgid, r=ehuss
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.
Joshua Nelson [Sat, 27 Nov 2021 19:08:14 +0000 (14:08 -0500)]
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.
- 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.
Joshua Nelson [Tue, 30 Nov 2021 19:25:55 +0000 (14:25 -0500)]
When documenting private items in a binary, ignore warnings about links to private items
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.
bors [Wed, 4 May 2022 00:02:04 +0000 (00:02 +0000)]
Auto merge of #10620 - weihanglo:snapbox-cargo-init, r=epage
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).
Auto merge of #10618 - dtolnay-contrib:checkoutv3, r=ehuss
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.
David Tolnay [Sat, 30 Apr 2022 20:46:35 +0000 (13:46 -0700)]
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.
#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.
Auto merge of #10611 - Muscraft:workspace-inheritance-documentaion, r=epage
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`.
Ed Page [Tue, 19 Apr 2022 17:18:20 +0000 (12:18 -0500)]
feat(test-support): Make multi-argument strings avaialble to snapbox
This is something the existing test infrastructure supports, so I
figured I'd make it mirror it for snapbox. I'm mixed.
- It reads more like what a user would type, making it easier to run a
test locally or take a manual test case and automate it
- It can make it harder to parse the arguments when scanning tests
- Without using a crate like `shlex`, the syntax support is unclear
projects / cargo.git / log