Skip to content

Add -Z hint-mostly-unused option to hint that most of a crate's API surface will be unused #883

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 of 3 tasks
joshtriplett opened this issue Jun 7, 2025 · 3 comments
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team to-announce Announce this issue on triage meeting

Comments

@joshtriplett
Copy link
Member

Proposal

Note: This was previously posted as an MCP for a -C option that required -Zunstable-options, but based on discussion at RustWeek, it sounds like that proposal had given the impression of wanting to rush stabilization, rather than being an unstable option to test and gather experience reports. Based on that discussion, I've opened this MCP to make it explicitly clear that this is an unstable option intended for a call for testing and for plumbing as a nightly Cargo option.

Some libraries are extremely large, and users use only a small fraction of their surface area. Crate features aren't ideal for just reducing the size of a very large library; that would require the crate maintainer to predict and provide semantic subsets that people will use, and commit to maintaining those subsets indefinitely as a stable API. That also doesn't scale well to crates with thousands of functions or structures; having thousands of features is a problem for maintenance, and for usability (carefully enabling the needed subset).

Introduce an option, -Z hint-mostly-unused, which hints to rustc that most of a crate's API surface area may go unused.

This option is a hint, and does not guarantee any particular behavior. Currently, this will make a crate defer compilation of as much of its code as it can, using the inlining machinery to provide its code as MIR, to be compiled only when referenced.

I've tested this on some crates with very large dependencies. On one project, adding this option to just the three largest dependencies reduced total compilation time from 10m30s to 6m12s.

I also intend to propose a corresponding nightly option in Cargo, which can be enabled on a per-dependency basis. (And, later, we can add a way for large crates to hint that they should have this option enabled by default unless overridden.)

Inspired by @saethlin's MIR-only rlibs work at rust-lang/rust#119017 .

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

@joshtriplett joshtriplett added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels Jun 7, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 7, 2025

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Jun 7, 2025
@joshtriplett
Copy link
Member Author

Implementation at rust-lang/rust#135656.

@lqd
Copy link
Member

lqd commented Jun 7, 2025

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jun 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team to-announce Announce this issue on triage meeting
Projects
None yet
Development

No branches or pull requests

3 participants