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`
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.
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.
Add documentation entry for unstable `--output-format` flag
This is a follow-up to #12252 adding a documentation entry for the newly supported unstable flag `--output-format`.
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>
feat: Add `rustc` style errors for manifest parsing
#12235 is tracking user control over warnings. One part of that is making `cargo`'s diagnostic system output messages in the style of `rustc`. To make it so that `cargo` doesn't have to manage a formatter and renderer, I decided to use [`annotate-snippets`](https://crates.io/crates/annotate-snippets), which matches `rustc`'s style well (at one time it was meant to be the formatted for `rustc`).
To get this work kicked off, it was suggested to me that we should start with styling manifest parsing errors, and that is what his PR does.
What manifest parsing errors look like after this change:
---
Note: `cargo` does not currently match `rustc` in color (#12740), `rustc` specifies their colors [here](740cea81d6/compiler/rustc_errors/src/lib.rs (L1755-L1768)) and [here](740cea81d6/compiler/rustc_errors/src/emitter.rs (L2689-L2723)). I used `annotate-snippets` default colors which match what `rustc` currently uses for colors. I did this as a stopgap while I work to unify the colors used between `rustc` and `cargo`.
---
Note: the error messages come directly from `toml` and can be quite long. It would be nice if we could put some of the message below the highlight but this would require changes to `toml`.
Example:
```
error: invalid type: integer `3`
--> Cargo.toml:7:7
|
7 | bar = 3
| ^ expected a version string like "0.9.8" or a detailed dependency like { version = "0.9.8" }
|
```
Document why `du` function uses mutex
### What does this PR try to resolve?
After closing #13253, it [was suggested](https://github.com/rust-lang/cargo/pull/13253#issuecomment-1883286035) to document why the `du` function uses a `Mutex` instead of an `AtomicU64`. This will prevent others from making the same mistake I did. :)
### How should we test and review this PR?
N/A
### Additional information
N/A
crates-io: Set `Content-Type: application/json` only for requests with a body payload
### What does this PR try to resolve?
The `Content-Type` **request** header is only supposed to be used if the request comes with a body payload. `cargo` is currently sending it unconditionally, even for `GET` requests that typically don't have a payload attached to them.
This PR changes the implementation to only attach the header if the request has a body payload.
