The rustc `-Zhint-mostly-unused` flag tells rustc that most of a crate
will go unused. This is useful for speeding up compilation of large
dependencies from which you only use a few items. Plumb that option
through as a profile option, to allow specifying it for specific
dependencies:
```toml
[profile.dev.package.huge-mostly-unused-dependency]
hint-mostly-unused = true
```
To enable this feature, pass `-Zprofile-hint-mostly-unused`. However,
since this option is a hint, using it without passing
`-Zprofile-hint-mostly-unused` will only warn and ignore the profile
option. Versions of Cargo prior to the introduction of this feature will
give an "unused manifest key" warning, but will otherwise function
without erroring. This allows using the hint in a crate's `Cargo.toml`
without mandating the use of a newer Cargo to build it.
Add a test verifying that the profile option gets ignored with a warning
without passing `-Zprofile-hint-mostly-unused`, and another test
verifying that it gets handled when passing
`-Zprofile-hint-mostly-unused`.
The `is_false` function already exists in the standard library, as
`Not::not`; use that in `skip_serializing_if` rather than defining an
`is_false` function.
Instead of allowing any type in metadata, we were specifying fields like
`"string": "<any string>"`.
Found this when looking into #15030
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
I found a bug in the manifest parser and figured this would help make it
more obvious.
Since I was already changing the order, I figure I'm make things a
little more logical (user-facing first, implementtion details later)
This was mostly done by clippy via `clippy::doc_markdown`.
I then reviewed it to fix words that shouldn't have it or where `--fix`
put the backtick in the wrong location.
This is to bring us into conformance with the [Rust crate ownership
policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo-credential-1password` is declared as Experimental as it is
intended for the community but I was unsure if we wanted to commit to
full support for it. In my mind, the ideal thing to do would be to
expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the
ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended
for the wider ecosystem and I didn't see a reason to declare it
experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared
as Intentional as they are both used internally and intended for
others to use for logic that integrates with cargo/registries.
I wondered about these being Experimental or Internal instead.
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
