Plumb rustc -Zhint-mostly-unused flag through as a profile option

[joshtriplett]

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:

[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.

How to test and review this PR?

The tests in the testsuite demonstrate both that the option works as expected and that it gets ignored with a warning if not passing -Zprofile-hint-mostly-unused.

This will remain a draft until rust-lang/rust#135656 gets merged in rustc; once that happens, the "nightly" jobs will pass in CI.

[epage]

Been thinking more about this

• Is code-gen deferred to the direct caller (like inline), linking, or "unspecified" with the hope of eventually getting this in the linking step?
• What about an attribute for this?

[joshtriplett]

@epage It's very much intentionally unspecified what this hint does, so that it can be changed in the future if desired. Right now it acts like inline, but it could do more than that, or apply different heuristics.

What about an attribute for this?

Not sure what you mean by that. An attribute for what?

[epage]

What about an attribute for this?

Not sure what you mean by that. An attribute for what?

A #[maybe_unused] so it can be managed within a crate and the author can apply it piecemeal.

[joshtriplett]

What about an attribute for this?

Not sure what you mean by that. An attribute for what?

A #[maybe_unused] so it can be managed within a crate and the author can apply it piecemeal.

I would expect that in the majority of cases where this hint is useful, it would apply to the vast majority of the crate, making it particularly inconvenient to tag such items with attributes.

(Also, in the future possibility of letting the crate provide the hint about itself in its own Cargo.toml, we might want some way to override that for crates that do use the majority of the API (e.g. a comprehensive binding).)

[epage]

On a similar note to an attribute is rust-lang/rust#54882.

For the cases where the hint would be used like that are likely code generated which removes the burden of adding it.

Yes, there wouldn't be overrides, that could maybe be put behind features but then we are back to adding features. At least those features are optional rather people dealing with possibly bad error messages to find out they need to add a feature.

I was wondering about it from the perspective of crates where the main part is always used but there are possibly unused subsets that would normally be put behind a feature. Say clap_complete was merged back into clap, we could have clap::complete and everything inside it would be #![maybe_unused] without needing a feature.

[joshtriplett]

@epage wrote:

I was wondering about it from the perspective of crates where the main part is always used but there are possibly unused subsets that would normally be put behind a feature. Say clap_complete was merged back into clap, we could have clap::complete and everything inside it would be #![maybe_unused] without needing a feature.

Ah, I see. That's an interesting idea. It's possible that a #[hint_maybe_unused] option for optimization purposes might be interesting; I don't think it's a replacement for this feature, but it's an interesting idea.

Right now, it's almost equivalent to #[inline(always)], so if you want to prototype whether that would help with compilation times, you could try that. (Keep in mind that it might be a performance loss for your own integration tests while being a performance gain for downstream crates.)

[epage]

Just waiting on rustc

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[joshtriplett]

r? @epage

The PR has been merged; waiting for nightly to be updated.