Proposal

In tidy, we reject code with comments of the form // TODO.*. Those are intended to be fixed before merging PRs. I like this behavior, it means you can set yourself tasks that you definitely cannot forget before merging. Curiously, we don't do the same for the todo!() macro, even though I'd like to use it for the same purpose. For example, in a match, to signify that I still want to implement that branch before merging.

I propose to also deny todo!() in tidy. As for when something is really left as TODO, and intended to be so after a PR is merged, I propose using unimplemented! instead to make it explicit that the branch is intended to be fixed in a later PR, not this one.

There are currently about 40 uses of todo!() in the compiler. Implementing the tidy rule is ~5 lines and the fixes are mostly trivial. Yet, I still thought it worth an MCP since this is a procedure everyone would have to follow if we accept.

Process

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

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.