Description
Proposal
It has been a long-standing issue that not having impl Copy
/#[derive(Copy)]
on a type that could have it results in worse Clone
codegen (rust-lang/rust#47796, rust-lang/rust#69174). A particularly extreme example of this can be found at https://godbolt.org/z/sKEbd6zPx.
This MCP proposes to move the Clone
derivation to be done at MIR, so that it is possible to take advantage of more type knowledge and know if a type could implement copy, or for short, it is "copyable"*. I have created a rough draft that does this move without the introduction of this "copyable" optimization at rust-lang/rust@master...octylFractal:rust:feature/derive-clone-in-mir, so it is possible to at least move the derivation. The next step would be to refine this change, and introduce a "copyable" query to allow this new derivation code to emit *self
for "copyable" types, and for the MIR -> IR lowering to accept *self
for types that are "copyable" and generate the same code as implementing Copy
would allow.
* A more formal definition of "copyable": a type T
is "copyable" if T: Copy
or if it is an ADT and all of its field are "copyable"
Mentors or Reviewers
@Aaron1011's comment here inspired some of the work, so they might be interested.
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.
- 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.