PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
Fixes#14476
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.
This is a partial revert of ##14121
(e11d1722bb6e1e58c91adb1964993c74b45f4293)
Our focus for redacting (auto or with globs) includes
- run-specific information (timing, hashes, platform-specific wording)
- rustc-specific information
(We tend to use globs for rustc-specific information because there might
be some very specific times we need to care about some of the details)
However, "Packaged files" does not fit into any of that and, for now, we
are erring on the side of redacting less, rather than more, with the
move to snapbox.
As we see how it works out and what the underlying requirements are, we
can revisit this.
test: Auto-redact file number
This is from <https://github.com/rust-lang/cargo/pull/14096#discussion_r1648889843>.
Although the number of files in `cargo package` is important,
we have `validate_crate_contents` and `validate_upload_with_contents`
that verify the exact contents.
Redacting `Packaged` status should be fine.
I got a CI failure because the following line showed up:
```
[WARNING] build failed, waiting for other jobs to finish...
```
I'm assumin this is a race condition in the test for whether the
successful target completed before the error or not.
Before snapbox, we used a `contains` check which didn't have this
problem. I'm replacing this with a `...` multi-line (0+) glob.
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 could offer performance gains when parsing a published
manifest since the targets don't need to be discovered.
To see this, we'd first need to stop discovering potential targets even when it isn't
needed.
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.
I've wanted something like this myself. I dislike using `--open`
because I tend to move up to re-run my `cargo doc` run but then have to
edit it to remove `--open`.
Also makes it annoying when opening docs when `cargo doc` is wrapped by
a tool like `make`.
This was previously attempted in #5592:
- Unlike the request in #5562, this aligns with #5592 in always printing
rather than using a flag as this seems generally useful
- Unlike #5592, this prints as an alternative to "Opening" to keep
things light
- Unlike #5592, this prints afterwards as the link is only valid then
Fixes#5562
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.
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
Error message for transitive artifact dependencies with targets the package doesn't directly interact with
Address #11260. Produces an error message like described by `@weihanglo` [here](https://github.com/rust-lang/cargo/issues/11260#issuecomment-1400455203):
```
error: could not find specification for target "x86_64-windows-msvc"
Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".
```
Note that this is not a complete fix for #11260.
`{ …, artifact = "bin", target = "target" }` should also be considered
to being built for `FeaturesFor::ArtifactDep` instead of `NormalOrDev`.
[This line][1] requests for `ArtifactDep` but [here][2] Cargo ignore
assumed host target of artifact dep.
Change it to explicit set host target triple when
- `{ …, target = "target" }`, and
- `--target` is not presented, meaning it would be build on host platform.
[1]: 1382b44e43/src/cargo/core/compiler/unit_dependencies.rs (L887)
[2]: 1382b44e43/src/cargo/core/resolver/features.rs (L857)
> Adapted from #11183
Previously, `is_dep_activated` depends on `activated_dependencies`,
which is a map of `PackageFeaturesKey` to its own activated `DepFeature`s.
`PackageFeaturesKey` in feature resolver is always comprised of
* A `PackageId` of a given dependency, and
* A enum value that helps decoupling activated features for that dependency.
Currently depending on the type of given dependency.
Looking into issue 10526, it has an `activated_dependencies` of
```
{
(mycrate, NormalOrDev) -> [dep:mybindep]
}
```
However, this [line][1] accidentally use a parent's `pkgid`
and a dependency's `FeaturesFor` to compose a key:
```
(mycrate, ArtifactDep("x86_64-unknown-linux-gnu"))
```
That is never a valid key to query features for artifacts dependency.
A valid key should be comprised of components both from the parent:
```
(mycrate, NormalOrDev)
```
Or both from the dependency itself:
```
(mybindep, ArtifactDep("x86_64-unknown-linux-gnu"))
```
This `unit_for` is from parent and should already contain its own
artifact dep information inside `artifact_target_for_features`,
so we don't need to map any dependency artifact from `dep.artifact()`.
[1]: a2ea66bea6/src/cargo/core/compiler/unit_dependencies.rs (L1106-L1107)
