Walkthrough of a Typical Contribution to the Rust Compiler

# Walkthrough: a typical contribution  There are _a lot_ of ways to contribute to the Rust compiler, including fixing bugs, improving performance, helping design features, providing feedback on existing features, etc. This chapter does not claim to scratch the surface. Instead, it walks through the design and implementation of a new feature. Not all of the steps and processes described here are needed for every contribution, and I will try to point those out as they arise. In general, if you are interested in making a contribution and aren't sure where to start, please feel free to ask! ## Overview The feature I will discuss in this chapter is the `?` Kleene operator for macros. Basically, we want to be able to write something like this: ```rust,ignore macro_rules! foo { ($arg:ident $(, $optional_arg:ident)?) => { println!("{}", $arg); $( println!("{}", $optional_arg); )? } } fn main() { let x = 0; foo!(x); // ok! prints "0" foo!(x, x); // ok! prints "0 0" } ``` So basically, the `$(pat)?` matcher in the macro means "this pattern can occur 0 or 1 times", similar to other regex syntaxes. There were a number of steps to go from an idea to stable Rust feature. Here is a quick list. We will go through each of these in order below. As I mentioned before, not all of these are needed for every type of contribution. - **Idea discussion/Pre-RFC** A Pre-RFC is an early draft or design discussion of a feature. This stage is intended to flesh out the design space a bit and get a grasp on the different merits and problems with an idea. It's a great way to get early feedback on your idea before presenting it to the wider audience. You can find the original discussion [here][prerfc]. - **RFC** This is when you formally present your idea to the community for consideration. You can find the RFC [here][rfc]. - **Implementation** Implement your idea unstably in the compiler. You can find the original implementation [here][impl1]. - **Possibly iterate/refine** As the community gets experience with your feature on the nightly compiler and in `std`, there may be additional feedback about design choice that might be adjusted. This particular feature went [through][impl2] a [number][impl3] of [iterations][impl4]. - **Stabilization** When your feature has baked enough, a Rust team member may [propose to stabilize it][merge]. If there is consensus, this is done. - **Relax** Your feature is now a stable Rust feature! ## Pre-RFC and RFC > NOTE: In general, if you are not proposing a _new_ feature or substantial > change to Rust or the ecosystem, you don't need to follow the RFC process. > Instead, you can just jump to [implementation](#impl). > > You can find the official guidelines for when to open an RFC [here][rfcwhen]. An RFC is a document that describes the feature or change you are proposing in detail. Anyone can write an RFC; the process is the same for everyone, including Rust team members. To open an RFC, open a PR on the [rust-lang/rfcs](https://github.com/rust-lang/rfcs) repo on GitHub. You can find detailed instructions in the [README](https://github.com/rust-lang/rfcs#what-the-process-is). Before opening an RFC, you should do the research to "flesh out" your idea. Hastily-proposed RFCs tend not to be accepted. You should generally have a good description of the motivation, impact, disadvantages, and potential interactions with other features. If that sounds like a lot of work, it's because it is. But no fear! Even if you're not a compiler hacker, you can get great feedback by doing a _pre-RFC_. This is an _informal_ discussion of the idea. The best place to do this is internals.rust-lang.org. Your post doesn't have to follow any particular structure. It doesn't even need to be a cohesive idea. Generally, you will get tons of feedback that you can integrate back to produce a good RFC. (Another pro-tip: try searching the RFCs repo and internals for prior related

This section walks through the process of contributing a new feature to the Rust compiler, using the `?` Kleene operator for macros as an example. The process includes idea discussion (Pre-RFC), formal proposal (RFC), implementation, iteration based on community feedback, stabilization, and finally, release as a stable feature. The author emphasizes the importance of early feedback and thorough research before submitting an RFC.