Add [hints] table in Cargo.toml, and a hints.mostly-unused hint
#15673
Conversation
rustbot
added
A-build-execution
|
Sorry if this is the wrong place for this, but I'd love to see how this affects a simple binary using the |
|
Note: should add a test for |
For a crate depending on aws-sdk-ec2, a release build went from 4m07s to 2m04s, and a non-release build went from 2m26s to 1m28s. |
joshtriplett
force-pushed
the
hints
branch
5 times, most recently
from
02f4153 to
9812504
Compare
|
@rfcbot fcp merge This insta-stabilizes a new While this is blocked on rustc, I figured we could run our FCP in parallel. |
|
Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
| #[cfg_attr( | ||
| feature = "unstable-schema", | ||
| schemars(with = "Option<TomlValueWrapper>") | ||
| )] | ||
| pub mostly_unused: Option<toml::Value>, |
There was a problem hiding this comment.
nit: you could do schemars(with = "Option<bool>") to communicate the effective schema even if the types take the long way around to get to it
There was a problem hiding this comment.
If I do that, the schema then says it takes a boolean or null, and I think that's incorrect; anyone relying on that schema would become fragile and potentially break if we introduce new possible values for this field. I think the schema should say that it takes a TomlValue or null.
The schema shouldn't encourage people to be brittle, when cargo is going out of its way to be permissive and allow for future evolution without it being a breaking change.
There was a problem hiding this comment.
I think its dependent on how the schema is being used, whether its prescriptively match our compatibility guarantees or to describe the behavior at this time. For example, some editors support reading these schemas and applying completions off of it.
I lean towards the latter but not going to push it. We can always adjust later.
There was a problem hiding this comment.
@epage I really don't know how the schemas are intended to be used. I don't object to this change, I just don't know how we expect people to handle compatibility with anything that gets generated based on this.
|
Sorry for the last minute finds |
joshtriplett
force-pushed
the
hints
branch
3 times, most recently
from
b06391f to
a6c0e06
Compare
rustbot
removed
the
S-waiting-on-review
Update cargo 1 commits in eabb4cd923deb73e714f7ad3f5234d68ca284dbe..6833aa715d724437dc1247d0166afe314ab6854e 2025-07-09 22:07:55 +0000 to 2025-07-13 02:25:52 +0000 - Add `[hints]` table in `Cargo.toml`, and a `hints.mostly-unused` hint (rust-lang/cargo#15673)
The
[hints]table in aCargo.tomlmanifest provides optionalinformation 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-unusedhint, which allows a package to hint that mostusers 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 = falseintheir profile for a dependency.
In the future, this same mechanism could be used for other hints, such as
min-opt-level.How to test and review this PR?
This PR is built atop #15643 . I'd
suggest reviewing that PR separately, then just reviewing the new commits in
this PR.
The new "hints" testsuite module demonstrates the expected behavior of hints.
Like #15643 , the nightly-only tests
will only pass once rust-lang/rust#135656 has been
merged into Rust.