-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Clarify stages of MIR pipeline, and make MIR lints consistent #72515
Copy link
Copy link
Open
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlC-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlC-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The
rustc_mir::transformmodule defines the pipeline of analysis passes and transformations that run on the MIR after it is lowered but before it is passed to codegen. However, it's not always clear whether certain invariants apply to each stage of the pipeline. For example, some terminators (FalseEdges,DropAndReplace) are removed entirely and do not appear beyond a certain point and theReturnterminator, which initially appears only once in the entire MIR body may appear multiple times after thegeneratortransform.Additionally, it can be hard to find the right place for new error-emitting passes like the lint in #72270 or #71824. Is there a point at which the MIR is no longer meant for analysis but only for codegen? Should these be part of a specific query? Finally, the names of the
mir_*queries have lost their meaning over time:mir_constcan probably be removed entirely, andoptimized_mirandpromoted_mirshould probably be renamed tomir_optimizedandmir_promoted_fragments_optimizedrespectively.I've listed quite a few issues above, but to resolve them I think we first need to figure out who the stakeholders are. Is there anyone who "owns" the current structure and has a clear idea of how things should look?