Description
Proposal
I am writing this because I keep tripping over the polymorphization implementation while working on post-mono MIR optimizations. I want there to be a point in the compiler where entire MIR bodies are fully monomorphized and then they stay monomorphized. The current polymorphization implementation breaks that mental model, in at least two ways:
- Anything that has been touched by polymorphization must not be re-monomorphized. This is surprisingly fiddly to uphold, because the current monomorphization strategy is that each rustc crate defines its own
fn monomorphizeand uses it to monomorphize individual consts, operands, etc. - This comment is entirely correct; polymorphization means we cannot use
TypingEnv::fully_monomorphizedeven though this is after monomorphization. https://github.com/rust-lang/rust/blob/b19329a37cedf2027517ae22c87cf201f93d776e/compiler/rustc_ty_utils/src/abi.rs#L48-L63
So there's this rake, and I keep stepping on it, and it's quite annoying.
I've done a GitHub code search for the flag and I cannot find any actual users: https://github.com/search?type=code&q=-Zpolymorphize+NOT+repo%3Arust-lang%2Frust++NOT+repo%3Amatthiaskrgr%2Ficemaker+NOT+repo%3Amatthiaskrgr%2Fglacier+NOT+repo%3Amatthiaskrgr%2Fglacier2+NOT+repo%3Arust-lang%2Fzulip_archive+NOT+path%3A%C2%B7tests%2Fui%2F*+NOT+path%3Atests%2Fui%2F*%2F*+NOT+path%3Atests%2Fui%2F*%2F*%2F*+NOT+path%3A%C2%B7src%2Ftest%2Fui%2F*+NOT+path%3Asrc%2Ftest%2Fui%2F*%2F*+NOT+path%3Asrc%2Ftest%2Fui%2F*%2F*%2F*+NOT+repo%3Adavidtwco%2Fzulip_archive+NOT+path%3Atests%2Fcrashes%2F*.rs&p=1
It doesn't make a whole lot of sense to be spending maintenance effort on a feature that may have users we can't see, but they are so few that none are public on GitHub.
There are a few more details about the current state and history in the feature's tracking issue, including a link to a sketch of a redesign: rust-lang/rust#124962
Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention them
here. You can put your own name here if you are planning to mentor the
work.
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 mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- 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.