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
`cargo update --precise` might pass in any arbitrary Git reference,
and `git2::Oid::from_str` would always zero-pad the given str if it is
not a full SHA hex string.
This introduces an enum `Revision` to represent `locked_rev`
that is either deferred or resolved to an actual object ID.
When `locked_rev` is a short ID or any other Git reference,
Cargo first performs a Git fetch to resolve it (without --offline),
and then locks it to an actual commit object ID.
This adds a set of tests which validates various edge cases around how
`cargo fix` works in terms of calling `rustc` multiple times. This uses
a replacement of `rustc` so it doesn't depend on the behavior of rustc
itself which is not always stable.
`cargo add` - fix for adding features from repository with multiple packages.
Fixes#13121
As discussed in the issue, when using `cargo add` to add a package with features from a git repository from one of it's members, the command might fail due to improper target for querying for said features.
This PR adds a test for this edge-case where we expect it to fail with current code. It also adds a fix for this, and updates the test to expect success.
While populating available features, the current code does a `Fuzzy` search which might lead to searching for features in a wrong member package. If we change it to an `Exact` query, we get back the proper member to search within.
