In most cases, this will just be what you passed on the command line.
Even when its not, that likely represents a programmer error.
I mostly did this to help see what was the cause of a test failure.
This commit fixes a (five year old!) regression in `cargo metadata`
where if `--filter-platform` isn't explicitly specified it will
accidentally read `$CARGO_BUILD_TARGET` (or `build.target`
configuration) and use that as the default `--filter-platform`. The
reason for this is that the calculation for targets changed in #8167
and while the shared function makes sense for other commands such as
`cargo build` the targets have a different meaning in `cargo metadata`
so a slightly different set of functionality is desired.
This commit fixes the issue by introducing a new constructor for the
list of `CompileKind` variants where the fallback of "if nothing is
specified" is explicitly chosen.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
cargo: prevent dashes in lib.name
The TOML parser of Cargo currently refuses `lib.name` entries that contain dashes. Unfortunately, it uses the package-name as default if no explicit `lib.name` entry is specified. This package-name, however, can contain dashes.
Cargo documentation states that the package name is converted first, yet this was never implemented by the code-base.
Fix this inconsistency and convert the package name to a suitable crate-name first.
This fixes#12780. It is an alternative to #12640.
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`
The TOML parser of Cargo currently refuses `lib.name` entries that
contain dashes. Unfortunately, it uses the package-name as default if no
explicit `lib.name` entry is specified. This package-name, however, can
contain dashes.
Cargo documentation states that the package name is converted first, yet
this was never implemented by the code-base.
Fix this inconsistency and convert the package name to a suitable
crate-name first.
Before the default was hardcoded to `true`. The problem was that means
that to remove the `package.version` boilerplate, you had to add
`package.publish = false` boilerplate.
To make the errors easier to understand in this situation, I err on the
side of encouraging people to put `publish = true` in their manifests.
By making this change, we also unblock "cargo script" /
`Cargo.toml` unifying the handling of `package.publish`.
This defaults the version to `0.0.0` for most of cargo.
It is an error to lack a version and have a package publishable.
That means you have to add `publish = false`.
Previous, `cargo metadata` allows a dependency with different renamed
co-exist. However, its `resolve.nodes.deps` will miss that dependency,
which is wrong. After this commit, `cargo metadata starts erroring out
for that situation.
This refactor reuse the logic of
`core::compiler::unit_dependencies::match_artifacts_kind_with_targets`
to emit error if there is any syntax error in `ArtifactKind`.
It also put `match_artifacts_kind_with_targets` to a better place `core::compiler::artifact`.
