fix(cli): Improve errors related to cargo script
### What does this PR try to resolve?
Fixes#13332
### How should we test and review this PR?
See tests in last commit to see how this changes error messages.
This is a lot of duplication with minor tweaking that will go away on stabilization
### Additional information
External subcommands are already able to inherit the jobserver from
env since #10511. However, users reported that they've expected
`cargo run` to behave the same as external subcommands.
A popular example "cargo-xtask" pattern is used as scripting to run
arbitrary tasks. Users may want to invoke `cargo run` from Make and
expect some parallelism. This PR provides such an ability to the
general `target.<...>.runner`, which affects `cargo test`,
`cargo bench`, and `cargo run`.
Note that this PR doesn't create any jobserver client if there is no
existing jobserver from the environment. Nor `-j`/`--jobs` would create
a new client. Reasons for this decision:
* There might be crates don't want the jobserver to pollute their
file descriptors, although they might be rare
* Creating a jobsever driver with the new FIFO named pipe style is not
yet supported as of `jobserver@0.1.26`. Once we can create a named
pipe-based jobserver, it will be less risky and inheritance by
default can be implemented.
Fix static_mut_ref warning.
The nightly compiler has recently added the [`static_mut_ref`](https://doc.rust-lang.org/nightly/rustc/lints/listing/warn-by-default.html#static-mut-ref) lint, which warns about taking a reference to a `mut static`. This fixes the issue by copying the value instead of taking a reference. I don't recall what I was thinking when I wrote this, but it was probably a bad reflex against making copies.
chore: Make MSRV=N-2 the workspace default
### What does this PR try to resolve?
Since we update the MSRV every release, `cargo bump-check` forces the changed packages to be released (#13266).
A caveat is that `cargo bump-check` only checks the directory and doesn't do a `.crate` diff, so it misses out of changes to `workspace.package`.
Because of our current workspace default, this means every 6 weeks we ship our user-facing packages but not the internal ones.
This shifts that so we ship our internal packages every 6 weeks and our internal only when changed.
### How should we test and review this PR?
### Additional information
If `rust-version = "auto"` (rust-lang/rfcs#3537) gets approved, then we will only ship packages that actually change
We likely don't want to release these packages every 6 months just for
an MSRV bump.
By moving the MSRV out of the package, `cargo bump-check` will ignore
the MSRV bump.
Inspired by #13266
This will require a version bump every release but over-releasing these
packages is likely a lot better than over-releasing the N-3 packages,
which we won't have to do anymore after this.
My hope is the `auto` value will be approved and stabilized and then we
won't have to over-release anymore.
I removed it from `cargo-test-support` and `cargo-test-macro`, despite
people depending on those (via git) because my long term plan is resting
on the `auto` value which won't affect git dependencies.
Improve GitHub Actions CI config
This pull request improves Cargo CI by:
1. Explicitly listing the branches the main CI should be run on (to avoid running on unwanted branches, particularly in forks)
2. By adding a [concurrency](https://docs.github.com/en/actions/using-jobs/using-concurrency) config so that only one "CI" runs for each "group" (one by PR), very inspired by rust-lang/rust [one](c485ee7147/.github/workflows/ci.yml (L35))
3. ~~By making all the jobs run only if triggered from this repository (to avoid having forks unnecessarily run CI jobs)~~
4. ~~By making all the checkouts take `fetch-depth: 2` like done in [rust-lang/rust](c485ee7147/.github/workflows/ci.yml (L452-L455)) (to avoid unnecessary work, saves bandwidth and maybe a bit of time)~~
5. Included `refs/heads/try` in the `success` and `failure` bors job gates (to fix `bors try` from timing out)
The main motivation for this PR was (at first) to make the CI jobs not run on forks since it's a waste of CI resources as well as always failing (like [this](https://github.com/Urgau/cargo/actions/runs/7567435677/job/20606586124)); but after looking at the `main.yml` config I took the opportunity to improve the situation by using rust-lang/rust [ci.yml](https://github.com/rust-lang/rust/blob/master/.github/workflows/ci.yml) as reference.
Go back to passing an empty `values()` when no features are declared
This PR is basically a revert of https://github.com/rust-lang/cargo/pull/13011, which made the `--check-cfg` invocation be `cfg()` when no features are declared instead of `cfg(feature, values())` since it meant declaring that the config `feature` were to be available in this form: `#[cfg(feature)]`, which is not the case.
Thankfully after some brainstorming, I [proposed](https://github.com/rust-lang/rust/pull/119930) changing the behavior of empty `values()` in `rustc` to no longer imply the _none_ value and simply create an empty set of expected values. 😃
For Cargo, always using `cfg(feature, values(...))` means that the config `feature` is always expected, regardless of the number of features. This makes the warning better, as it will now always be `unexpected config value` (instead of `unexpected config name`). 🎉
Fixes https://github.com/rust-lang/cargo/pull/13011#issuecomment-1819427800 as well as the concern in the [tracking issue](https://github.com/rust-lang/cargo/issues/10554).
r? `@epage`
Previously if a value from `--package` flag contains `?`, Cargo
considered it as a glob pattern. However, staring from 12933 the
Package Id Spec has been extended to accept `?` for git sources.
This PR adjust accordingly to accept `?` from `--package` flag
when it is a valid Package Id Spec.
In 12914 we stabilized pkgid spec as unique package identifier for
`cargo metadata`. However, we forgot to make the same change to
JSON message format[^1]. This PR does so.
Note that the `package_id` field in JSON message is not clearly stated
as "opaque", so it might be considered as a breaking change to some extent.
[^1]: https://doc.rust-lang.org/nightly/cargo/reference/external-tools.html#compiler-messages
doc(features): Highlight the non-blocking feature gating technique
We already discussed non-blocking gates but the language makes it sound like it was limited to `config.toml`.
Since I haven't been touching that, I had always overlooked that section.
This change brings the blocking / non-blocking decision front and center.
To support this, the later sections focus more on mechanisms (the gate) rather than on what is being done (new syntax for `cargo-features`).
I also feel this makes the content more scannable.
This is adapted from what I did for `[lints]` (see #12148).
We already discussed non-blocking gates but the language makes it sound
like it was limited to `config.toml`.
Since I haven't been touching that, I had always overlooked that
section.
This change brings the blocking / non-blocking decision front and
center.
To support this, the later sections focus more on mechanisms (the gate)
rather than on what is being done (new syntax for `cargo-features`).
I also feel this makes the content more scannable.
This is adapted from what I did for `[lints]` (see #12148).
doc: add a heading to highlight "How to find features enabled on dependencies"
### What does this PR try to resolve?
Maybe fixes https://github.com/rust-lang/cargo/issues/13289
Add a title to highlight "How to find features enabled on dependencies"?
### How should we test and review this PR?
### Additional information
