Description
Proposal
This proposal aims to establish a "macros-wg" with both basic and advanced goals. The advanced goals will be pursued in the future only if, after one year, this work is confirmed to be effective through another MCP.
Currently, the macros system in the compiler is more like a "dead zone" where it is difficult to make any progress with nightly features that have been in nightly forever or propose new changes or bug fixes.
In this proposal, we take into consideration two use cases:
In the past year, it has been difficult to give attention to this area for two main reasons:
- Experts in this area lack time, and no new experts have emerged.
- There is no interest in changing this area, and perhaps it is considered a stable but tricky area (which it is) where making changes that could introduce regressions is challenging. Therefore, getting work done can be tricky or require more effort due to backward compatibility.
An important role for the WG is to bootstrap the experience necessary to make deeper changes to the macro system and to review changes to the PR system.
By discussing with some people that help me to write down the full WG idea, a good idea to achieve this might involve group review of the existing system, building confidence by fixing bugs, and/or having some kind of reading group for discussing the academic work behind the macro system.
Basic Goals
- Revive old work, such as:
- Diagnostic improvements in procedural macros to make Rust more accessible when using proc macros.
- Bug fixing that has been overlooked.
- Rebuild or update the Rust macros book (covering both basic and advanced concepts) where the reader of the book will be able to process a syn-like crate in order to have alternative ideas.
- Conduct more in-depth studies in this area and experiment with declarative macros 2.0 using new crates.
- Conduct research and experimentation on libraries for proc macros (e.g., kproc-macros):
- While tools like syn are great, conducting research in this area can lead to improvements in the proc macro API by experimenting with additional crates that make writing proc macros easier.
Advanced Goals
These goals need to be confirmed with another MCP after one year of this one.
- Clean up outdated nightly features.
- Conduct more thorough design work on declarative macro 2.0.
Mentors or Reviewers
Team Members
Currently, I put myself as one of the leaders of the team, @vincenzopalazzo, where I have time to organize and manage the work. However, the following people are proposed with the following roles:
- Eric Holk: Co-leader, as an experienced person in language design and already a well-known figure in the ecosystem as part of different working groups.
- Jacob Pratt: Team Member, as a well-known Rust contributor and one of the person who tried to make some work on the Rust macro system in past 2 years. It is valuable to have people who have already worked on the macro system.
- Lukas Wirth: Team Member, as someone working on rust-analyzer, would provide a practical point of view on macros from an IDE perspective. He is also one of the authors for the updated The Little Book of Rust Macros.
- Arthur Cohen: Team Member, as a GCC Rust maintainer and implementer of the macros code in GCC, could offer another valuable point of view on the macros API/semantics.
- Daniel Henry-Mantilla: Team Member, as a well-presented figure in the issue and Zulip thread, providing useful feedback for API discussions and bug report support by providing MCVE (Minimal, Complete, and Verifiable Examples).
In this team, we also have a group of unofficial members (aka Fellows) that we hope to mentor them and to include inside the team when the times come.
Finally, I have also been in touch with a few people who are interested in macros work but are not able to commit to WG membership, so we are planning to involve them as well by leading the discussion all in public and give a change to join us.
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.