In #7295 (released in 1.39), we said we'd want to warn on use of
`.cargo/config` after about 6 months. Over 4 years later, we are now
getting that warning.
This is important for addressing user confusion, like in
https://www.reddit.com/r/rust/comments/19fd5q2/cargoconfig/
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.
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
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).
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`
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`
Implementation of shallow libgit2 fetches behind an unstable flag
This is my first contribution, so guidance is appreciated.
Fixes#1171 by moving the `shallow-index` and `shallow-deps` aspects of `-Zgitoxide` to a new `-Zgit` unstable flag.
The only change in interaction with libgit2 happens in `src/cargo/sources/git/utils.rs`, where we set the depth fetch option if applicable.
Shallow fetch tests for gitoxide continue to pass, but libgit2 is harder to test as it silently ignores the depth option for local fetches. I would love any ideas on how to test it in a lightweight way or whether it's OK to wait for an upstream fix.
doc: add `public` info in `cargo-add` man page.
### What does this PR try to resolve?
follow up https://github.com/rust-lang/cargo/pull/13046
add `public/private` explanation for `cargo-add` in man page.
### How should we test and review this PR?
### Additional information
The help info would be like this
- `cargo help add`
```
--public
Mark the dependency as public.
The dependency can be referenced in your library’s public API.
Unstable (nightly-only) <https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency>
--no-public
Mark the dependency as private.
While you can use the crate in your implementation, it cannot be referenced in your public API.
Unstable (nightly-only) <https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency>
```
- `cargo add -h`
```
--public Mark the dependency as public (unstable)
--no-public Mark the dependency as private (unstable)
```
- `cargo add --help`
```
--public
Mark the dependency as public (unstable)
The dependency can be referenced in your library's public API.
--no-public
Mark the dependency as private (unstable)
While you can use the crate in your implementation, it cannot be referenced in your public API.
```
Add unstable `--output-format` option to `cargo rustdoc`
Add unstable `--output-format` option to "rustdoc"
We achieved this by:
* Handle `--output-format` argument, accepting `html` or `json`
* A new field `json` in `CompileMode::Doc`.
* If `json` is passed, we append the following in
`prepare_rustdoc`:
1. `-Zunstable-options`
2. `--output-format=json`
Fixes#12103
We achieved this by:
* Handle `--output-format` argument, accepting `html` or `json`
* If `json` is passed, we append the following in
`prepare_rustdoc`:
1. `-Zunstable-options`
2. `--output-format`
Fixes#12103
Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
Inspired by my having forgotten to add `[lints]` to the if sequence.
Previously, we added a comment to suggest this but the further the code
is, the harder it is to track.
I considered a custom `Deserialize` impl, possibly through a new type,
that would error.
This would be the more "pure" solution.
Unfortunately, this would also have worse errors because the errors
would be reported to the `Deserializer` at the document-level, rather
than directly on the individual fields.
Well, we don't do on individual fields now but it is something we will
soon be exploring.
The use of `flatten` was getting in the way of `serde_ignored`.
A common workaround is to add our own `unused` tracking but that would
cause duplicates with `workspace.lints` (or we'd just ignore it).
Since the manual deserializer was relatively simple, I went that route.
Fixes#12917
