Based on analysis of the current Rust Reference, some of the key areas of Rust that the Reference doesn't fully specify (and in some cases no documentation fully
specifies) are:

1. The behavior of **type inference**, including both when the language can infer types and the boundaries and limitations of when it cannot.
2. The **trait solver**. Fortunately, one of our own Rust engineers (lcnr) recently led a rewrite of the trait solver (https://blog.rust-lang.org/inside-rust/2024/12/04/trait-system-refactor-initiative/), and produced developer-focused documentation in the rustc dev guide (https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html ). They would be the perfect person to turn that into reference material, and collaborate on which portions should be specified and which should be left flexible for future expansion.
3. More details on **macros and expansion**, in general. Macros-by-example (declarative `macro_rules!` macros) are mostly covered, but not things like the exact behavior of proc macros and the general process such as cfg pruning.
4. **Name resolution**. The process by which the Rust compiler resolves a name used in Rust code, including methods of traits, and items imported from various modules in various crates. Name resolution includes various extensions and special cases, and the reference would need to document those and their behavior.
5. Completing documentation of **const eval**.

We expect to do a primary push for progress on the Reference in the next few months, through September, and further work through the rest of 2025.

In order to get this work into the upstream reference, we will also need to support the additional review load this work will create; e.g. reviewing existing Reference changes in order to free up others' capacity for reviews of our own changes.

There are several areas we can potentially make rapid progress in:
- lcnr, as the primary developer of the new trait solver, would be the perfect person to work on the trait solver documentation.
- Jack Huey has much experience with type inference, and would be able to provide reference documentation for it, as well as mentorship and review bandwidth.
- Jane Losare-Lusby can contribute material on name resolution and expansion, as well as mentorship and review bandwidth.
- Josh Triplett will provide coordination, mentorship, and review capacity, as well as potentially contributing material in the areas of macros and expansion.
- Amanieu d'Antras will contribute to const eval. Also, will provide mentorship and review capacity, as well aspotentially contributing material in the area of inline assembly syntax.
- Guillaume Gomez will provide mentorship and review capacity.
- Vadim Petrochenkov will provide mentorship and review capacity, especially in the area of name resolution.
- Mara Bos will provide mentorship, and coordination on the Huawei side.
- In addition, we can pair with some members of Yijun's ADA team (Midia, Luca & Vitali), who would also have the opportunity to get up to speed on the internals of the Rust compiler. We hope to leverage their availability (with mentorship from Mara Guillaume, Jane & others) to:
- help with research into the behavior of the compiler,
- to aid with the review load of PRs to the reference,
- and to ramp up and become additional compiler experts by pairing with our existing team members.

We hope to address at least 3-4 of the above key gaps in the next few months and get to the point of draft PRs.

**Note**: We do not attempt to focus on the **borrow checker**, **Ownership**, **ffi bounds**, **concurrency**, or **operational semantics**; since most of them require substantial effort.