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
Strip debuginfo when debuginfo is not requested
### What does this PR try to resolve?
This PR implements [this proposal](https://github.com/rust-lang/cargo/issues/4122#issuecomment-1868318860). It contains a detailed description of the change.
As a summary, this PR modifies Cargo so that if the user doesn't set `strip` explicitly, and debuginfo is not enabled for any package being compiled, Cargo will implicitly set `strip = "debuginfo"`, to strip pre-existing debuginfo coming from the standard library. This reduces the default size of release binaries considerably (~4.5 MiB => ~450 KiB for helloworld on Linux x64).
Perhaps we could only add the `-Cstrip` option for the leaf/root target (i.e., a binary), but cargo already passes `-Cstrip` to libraries if it's set by `[profile.<...>.package.<lib>]`, so it seems harmless.
Fixes: https://github.com/rust-lang/cargo/issues/4122
### How should we test and review this PR?
Best reviewed commit by commit. There is one commit that fixes an existing related test that was using wrong assertion.
### Additional information
The implementation of the deferred option was inspired by `DebugInfo`, which already uses a similar concept.
### Unresolved questions
Should we also do this on macOS by default? It [seems](https://github.com/rust-lang/cargo/issues/11641) that there can be some issues with `strip` there. If it doesn't work, it basically inhibits compilation in release mode, with no easy way to opt out (unless the user explicitly requests debuginfo, but that's not the same as the previous state).
Update ahash dependency to 0.8.7
Previous versions use the `stdsimd` nightly feature if it detects that it is available (on a nightly toolchain). This will stop working once rust-lang/rust#117372 is merged.
fix(metadata): Stabilize id format as PackageIDSpec
### What does this PR try to resolve?
For tools integrating with cargo, `cargo metadata` is the primary interface. Limitations include:
- There isn't an unambiguous way to map a package entry from `cargo metadata` to a parameter to pass to other `cargo` commands. An `id` field exists but it is documented as an opaque string, useful only for comparisons with other `id`s within the document.
- There isn't an unambiguous way of taking user parameters (`--package`) and mapping them to `cargo metadata` entries. `cargo pkgid` could help but it returns a `PackageIdSpec` which doesn't exist within the `cargo metadata` output.
This attempts to solve these problems by switching the `id` field from `PackageId` to `PackageIdSpec` which is a [publicly documented format](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), can be generated by `cargo pkgid`, and is accepted by most commands via the `--package` flag.
As the `"id"` field is documented as opaque, this technically isn't a breaking change though people could be parsing it.
For `cargo_metadata` they do [use a new type that documents it as opaque but publicly expose the inner `String`](https://docs.rs/cargo_metadata/latest/cargo_metadata/struct.PackageId.html). The `String` wasn't publicly exposed due to a request by users but instead their `PackageId` type replaced using `String`s in the API in oli-obk/cargo_metadata#59 with no indication given as to why the `String` was still exposed. However, you'll note that before that PR, they had `WorkspaceMember` that parsed `PackageId`. This was introduced in oli-obk/cargo_metadata#26 without a motivation given.
**Note that `PackageIdSpec` has multiple representation that might uniquely identify a package and we can return any one of them.**
Fixes#7267
### How should we test and review this PR?
### Additional information
cc `@oli-obk`
Previous versions use the `stdsimd` nightly feature if it detects that
it is available (on a nightly toolchain). This will stop working once
rust-lang/rust#117372 is merged.
Introduce `-Zprecise-pre-release` unstable flag
Tracking Issue: [#13290](https://github.com/rust-lang/cargo/issues/13290)
This change introduces the feature but does not yet attempt an implementation. The actual implementation will happen in future PRs.
r? `@epage`
Delete sentence about parentheses being unsupported in license
Parentheses have been supported by crates.io since 2 years ago.
- https://github.com/rust-lang/crates.io/pull/4257
Their functionality is tested by this test: 3acd63c1f3/tests/utils/license-test.js (L68-L79).
I think a separate test in Cargo is most likely not valuable because Cargo does not parse these license strings, they are just treated as `Option<String>`.
Here is an example of an extremely widely used package (147 million downloads) with parentheses in its license: https://crates.io/crates/unicode-ident.
