The `[hints]` table in a `Cargo.toml` manifest provides optional
information that Cargo can use for building the package, and will use
even when using the package as a dependency. All hints can be safely
ignored, and Cargo only warns about unknown hints, but does not error.
This allows packages to use hints without depending on new Cargo.
Add a `mostly-unused` hint, which allows a package to hint that most
users of the package will not use most of its items. This is useful for
improving the build performance of crates with large dependencies.
Crates can override this hint using `hint-mostly-unused = false` in
their profile for a dependency.
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)
