---
title: T-compiler 2022 Horoscope
---

# T-compiler 2022 Horoscope

## Doc 2022-02-04

Some people have been wondering about what the Rust Compiler Team has planned for 2022. This note is to let you all know what activities the team plans to focus on this year.

This document is structured into three parts: our [Overall Themes][] for this year, the [Concrete Initiatives][] we have resources to drive, and [Aspirations][] for what we could do if given more help.

[Overall Themes]: #Overall-Themes
[Concrete Initiatives]: #Concrete-Initiatives
[Aspirations]: #Aspirations

[toc]

## Introduction

Part of the motivation for this note is to encourage new contributors to get involved. We have a lot of newcomers, from individuals to large organizations, who are very excited about Rust's potential, and I want to show all of them what they can do to help.

In preparing this document, I reached out to the members of both the Compiler Team itself as well as the larger set of Compiler Contributors, to get ideas of what was important to them. Those responses, along with what wwiser and pnkfelix believe to be important, led to the following item listed below.

Some of these items are in the [Concrete Initiatives][] section; such items have an assigned owner (a person or working group) who has allocated time this year to attack the problem.

The other items are in the [Aspirations][] section. These are items that the team agrees would be great areas for investment, but where we currently lack sufficient expertise or development resources to make progress this year. You can think of that part of the doc as an explicit call to arms: If you see something there that interests you, please reach out to the person listed in that section to find out how you might be able to help.

Furthermore, if you think we have left something important out of this list, please do reach out. pnkfelix and wwiser are happy to discuss what items are on this list, and what items we explicitly decided to leave *off* the list.

## Overall Themes

There are three areas of improvement we will be looking at: [Delivering on Rust's Promise], the Rust [Developer Experience], and the Compiler [Contributor Workflow].

[Developer Experience]: #Developer-Experience
[Contributor Workflow]: #Contributor-Workflow
[Delivering on Rust's Promise]: #Delivering-on-Rusts-Promise

### Delivering on Rusts Promise

Delivering on Rust's Promise is a cross-cutting theme; it means identifying the gaps between expectation and reality for each of our three pillars: Performance, Reliability, and Productivity, and then addressing those gaps.

For Delivering on Rust's Promise, we must address the compiler and standard library's [soundness issues (concrete)][I-unsound]. We would also like to reduce the number of [high priority (P-high) issues (aspirational)][P-high] that Rust have accumulated over the years. There is ongoing work to improve [Async Rust (concrete)][Async Rust]. Finally, there is everpresent work to improve the Rust Compiler's [Diagnostics (aspirational)][Diagnostics].

[I-unsound]: #I-unsound-issues
[P-high]: #P-high-Aspirations
[Async Rust]: #Async-Rust
[Diagnostics]: #Diagnostics-Aspirations

### Developer Experience

Improving on the Rust Developer Experience means asking the question "what could we do to *delight* Rust developers?"

There were three themes we identified here, and all three have both concrete and aspirational components: Debugging ([concrete][Debugging concrete] and [aspirational][Debugging aspirational]) , Faster Compiles ([concrete][Faster concrete] and [aspirational][Faster aspirational]), and Language Expressiveness ([concrete][Expressiveness concrete] and [aspirational][Expressiveness aspirational].)

[Debugging concrete]: #Debugging-Initiatives
[Debugging aspirational]: #Debugging-Aspirations
[Debugging]: #Debugging-Object-Code
[Faster concrete]: #Compilation-Time-Initiatives
[Faster aspirational]: #Faster-Compilation-Aspirations
[Expressiveness concrete]: #Language-Expressiveness-Initiatives
[Expressiveness aspirational]: #Expressiveness-Aspirations

### Contributor Workflow

Finally, improving the Compiler Contributor Workflow means enhancements that benefit people maintaining and extending the Rust compiler itself. Sometimes such improvements take the form of meta-activity, such as revising our internal processes for proposing, discussing, and approving significant changes. But other times the improvements have a technical nature.

The themes identified under Compiler Contributor Workflow were Librarification ([concrete][Librarification Initiatives], [aspirational][Librarification Aspirations]) and [Compiler Backend (aspirational)][Compiler Backend] work.

[Librarification Initiatives]: #Librarification-Initiatives
[Librarification Aspirations]: #Librarification-Aspirations

[Compiler Backend]: #Compiler-Backend
[Review Queue Crew]: #Review-Queue-Crew

## Concrete Initiatives

This section is the closest thing to a "roadmap" in this document: it is a list of important items with a dedicated owner that has time allocated this year to make significant progress on the problem.

### I-unsound issues

As of this writing, we have 69 [open issues tagged I-unsound](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound), and 44 of those are [also tagged T-compiler](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound++label%3AT-compiler).

In theory, any unsoundness issue potentially undermines Rust's promise of "reliability." We want, by the end of this year, to have a clear understanding of how each of those I-unsound issues is *eventually* going to be resolved.

oli-obk will be the primary owner of work in this space. Please reach out to pnkfelix and oli-obk if you are interested in helping resolve these issues!

### Async Rust

There is significant overlap between async rust and other areas of this document, such as debugging and language expressiveness.

nikomatsakis and tmandry are driving the [async fn in traits initiative](https://github.com/rust-lang/async-fundamentals-initiative/issues/5), which will unlock the ability to write `async` methods of traits.

mw is driving the [async crashdump initiative](https://rust-lang.github.io/async-crashdump-debugging-initiative/), which will enable developers to understand the control-flow stacks encoded in crashdumps for their async Rust programs.

(There is a ton of other work being done in the Async Rust space; you can see the [Async Vision web site](https://rust-lang.github.io/wg-async/welcome.html) for for more information here.)

### Debugging Initiatives

pnkfelix and wwiser are spinning up a wg-debugging working group. It will cover at least the following sub-items: improving Rust's debuginfo quality (mw, wwiser), supporting split debuginfo (davidtwco), and better integration with trace-based debuggers like `rr` (pnkfelix).

### Compilation Time Initiatives

The Rust compiler's end to end latency is known to be a problem.

lqd is dedicating the majority of 2022 to working on this, partnering with wg-compiler-performance as well as performance ~~gurus~~ experts like nnethercote. lqd has their own [living document](https://hackmd.io/3Dp68rTDSpWvRDfWF6lbMw?view) that lists the areas they will be investigating.

### Expressiveness Initiatives

A common refrain we hear is: "I need feature X, but it's not implemented in rustc or stable." Many of those features have dedicated owners.

For example, Generic Associated Types, or [GATs](https://github.com/rust-lang/generic-associated-types-initiative/issues/4), are an ongoing effort owned by jackh726.

[`async fn` in traits](https://github.com/rust-lang/async-fundamentals-initiative/issues/5) is an ongoing effort owned by tmandry (already mentioned above).

And [safe transmute](https://github.com/rust-lang/lang-team/issues/21) is an ongoing effort being driven by jswrenn.

### Librarification Initiatives

These are initiatives dedicated to the "librarification" of the compiler: breaking the monolithic code base of `rustc` into a set of decoupled parts that can be independently developed, and, ideally, repurposed for other kinds of tools besides `rustc`.

#### Chalk

Chalk is a reimplementation of Rust's trait system using declarative logic rules, a la Prolog.

Chalk has been years in development, and has been experimentally integrated into rustc in the past. This year, jackh726 and nikomatsakis are owning the task of improving the chalk integration, to drive it to the point where the team can start considering migrating to it as the implementation of the trait system.

If you want to help out with this, reach out to jackh726 and nikomatsakis.

## Aspirations

We would love to get help in any of the areas listed on this document, but this section specifically lists areas where we know we lack resources today.

### P-high Aspirations

pnkfelix and wwiser, as team leads, are deploying processes to help us get a handle on the "high priority, but *not critical*" issues that the compiler has accumulated. We will be gradually identifying owners for each who will move progress forward, and in general working to keep better track of the set overall.

If you would like to help with the task of reviewing or resolving such issues, reach out to wwiser and apiraino, who are co-leads of WG-prioritization.

### Debugging Aspirations

We need more local expertise in debuginfo format(s): DWARF, Natvis.

We want better integration, at least with the popular debuggers. We want to add e.g. expression evaluation support. We also want to reevaluate our debugger extensions for data structures rendering.

We have direct contacts with experts in Windows-based debuggers and in LLDB debugging. We do not have any local expertise with extending `gdb` itself, nor any direct contacts with such expertise.

If you want to help out here, please reach out to pnkfelix and wwiser.

### Faster Compilation Aspirations

#### Open I-compiletime Issues

We have [154 open issues tagged `I-compiletime`][I-compiletime]. So there may be low-hanging fruit there for new-comers to try to assist.

If you are interested in any of these, reach out to lqd, who owns the end-to-end compilation time initiative for 2022.

[I-compiletime]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-compiletime

#### Parallel Compilation

Parallel Compilation is one avenue for improving compiler performance. It is also a very complex area, especially when it comes to the tradeoff of how much of a hit one is willing to take on single core machines with in order to enable more parallel computation. This is an area we think needs long-term collaborative effort with the compiler team. We do not expect to deliver a solution here this year.

If you want to discuss more with us about past attempts and ideas for the future, please reach out to pnkfelix and wwiser.

#### Incremental Compilation Aspirations

Incremental compilation performance and stability are both ongoing concerns to the team. We suspect there is much room to improve our testing of incremental compilation. We *know* there is significant room to improve the effectiveness of incremental compilation, in terms of reducing the amount of redunant work done by successive `rustc` invocations.

If you want to learn more, reach out to lcnr and Aaron Hill.

### Expressiveness Aspirations

const generics and const eval are making steady progress. There are a *lot* of feature flags, which implies there's a lot of knobs that could be turned on and off.

What we can probably use the most help with is in identifying what subset of the features we should be striving to stabilize in order to unlock specific use cases for Rust developers.

So, if you or your team is enthuastically awaiting const generics or const eval, reach out to lcnr and oli-obk.

### Librarification Aspirations

#### MIR tooling

Various stakeholders, especially in the formal methods space, are making extensions to Rust that are based on analyzing MIR, the intermediate representation used by the compiler. Should we be trying to stabilize that as an interop format of some kind?

Reach out to pnkfelix and wwiser if you are interested in helping us here.

### Compiler Backend Aspirations

#### Ease writing new backends

One source of tedium when defining a new Rust compiler backend is implementing the intrinsics that each backend must provide. But a small change to the intrinsic system: namely, allowing intrinsics to define a [fallback MIR implementation][], could ease that burden. Reach out to scottmcm if you are interested in helping out here.

[fallback MIR implementation]: https://github.com/rust-lang/rust/issues/93145

#### Cranelift

The [Cranelift Code Generator][Cranelift] is getting a lot of attention from various parties. rustc has a [Cranelift backend][]. If you are interested in helping out with it, reach out to bjorn3.

[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/main/cranelift
[Cranelift backend]: https://github.com/bjorn3/rustc_codegen_cranelift

### Diagnostics Aspirations

The Rust compiler has pretty good diagnotics. But the good news is, there's a [full employment theorem](https://en.wikipedia.org/wiki/Full_employment_theorem) for diagnostics engineers, and that sure is evident in the set of ... over ... 1,500 [open diagnostics issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-diagnostics).

Diagnostics improvements are an *excellent* first step for learning about how to contribute to the Rust compiler. If you're interested in helping out but don't have any idea where to start, fixing diagnostic bugs is a great jumping off point, and you can reach out to estebank to find out more about how to help.

## Conclusion

Reading over this list, the number of items on it seems quite daunting.

Do we really think we can get all this stuff done in one year?

No, we don't! :laughing:

The introduction explcitly said the latter half are things that *don't* have resources attached to them. And the word "aspiration" was chosen to reinforce that.

This is where you all, the Rust community (including *future members* of that community) come into the picture. Each item has one or two people listed with it; if you're feeling inspired, please do contact us!

# The Stuff Above Is What Gets Distributed to the Team and the Public

## Checkpoint circa 2022-02-05

# That's the End

# There's nothing below

## I mean it

Well that's not true, there are remmants of previous drafts, some notes from meetings, a pretty picture.

# Notes on Next Steps

* See also: Wesley's notes, here: https://hackmd.io/wqNbeIzaQPuVo1zYHRv0zQ?view

* Plan:
* Felix works 2022-02-04 on new doc for distribution
Rough structure:
1. List high-level categories
2. List of concrete goals, tagged with owners and categories
3. Aspirational goals, tagged with categories
* Wesley finds time to look at it over weekend, and/or Monday 2022-02-07
* Felix would like to send *something* to the T-compiler and T-compiler contributes either Monday night or Tuesday 2022-02-08.
* 2022-02-11 is planning meeting. Could schedule meeting to discuss doc on 2022-02-18, with expectation to then push to blog PR shortly thereafter. (If we get a lot of feedback in that meeting, then we hit brakes on blog post.)

* End Goal:
* Get alignment between external stakeholders and internal team
* other effects include: Rust users get insight into what may be coming down pipeline. (but we need to set expectations here accordingly.)

* Different Audiences:
* T-compiler and T-compiler-contributors
* External stakeholders
* Need to be *very* clear about which items are aspirational (i.e. *not currently resourced*) and which are concrete (i.e. have someone working on it and we are confident they will make progress)

* Things Felix and Wesley are aligned on
* debugging
* e.g. wg-debugging
* felix wants to mention split-debuginfo in doc too
* lot of some concrete goals, some aspirational
* compiler-perf
* lots (long-tail) of tiny investigations
* lots of massive (multi-man-year) projects, like parallel-rustc
* not too many medium sized projects known *yet*.
* for message to T-compiler/T-compiler-contributors, explicitly invite more ideas.
* wwiser: "10% each year is not sufficiently faster *fast enough*"
* rust codebases are probably growing a speed that matches or exceeds that, so the win gets washed out and people don't *feel* like its faster.
* once codebases hit a steadystate of size, then 10% wins each year *would* be faster enough.
* incr-comp vs end-to-end
* incr-comp is not good enough on rustc dev
* for incr-comp: but 4min vs 2min is not super-signicant. Need to get to the 30sec, 10sec, 5sec, etc.
* for end-to-end, minutes/hours for CI *is* huge.
* re parallel-comp, we would need more alignment from the team to see forward movement here
* should include private note to T-compiler and T-compiler-contributors on this point, and point out that lack of review capacity and wg-rustc-perf capacity is a huge issue here.
* *somebody* needs to step up and own "yes, we will accept `-j1` perf regression X in order to reap improvement Y."
* review-queue length
* for wwiser: for each PR, either: this is area I know well, or its small enough that I feel confident, *or* its something in a space I know nothing about. So then it takes gobs of time for wwiser to ramp up knowledge (by e.g. rustc-dev-guide).
* felix: how can we scale up reviewer bandwidth
* e.g. would it help to provide build artifacts
* or spin up specialized playpen
* or maybe extend play.rust-lang.org to be able to specify
* or have dedicated bors commands to handle "do this test on this target" (because its one that I know CI doesn't cover that I know this PR is supposed to deal with, or may have trouble with, etc)

* A company looking to sponsor wants to see a tangible ROI.
* Wesley's has this spelled out at end: https://hackmd.io/wqNbeIzaQPuVo1zYHRv0zQ?view
* formal-methods (and thus MIR tooling) shoud be added to that list

* Spell out "this is the reality of working on an volunteer-driven open source project: we have aspirations. Some of them have volunteers driving them. Some of them have employees working on them. And some have nobody."

# Introduction

(I called this document a "road map" in my original planning, but given that it is meant to include wishes/hopes as well as resourced work items, I decided a bit of whimsy might be in order.)

There are three primary themes I want to focus on in the document: Improving the Rust Developer Experience, Improving the Compiler Contributor Experience, and Delivering on Rust's Promise.
* The Compiler Contributor Experience is meant to always be in service of the Rust Developer Experience: enhancements to rustc development mean a better rustc in the hands of Rust developers.
* Of course sometimes the other direction works out as well, since rustc is written in Rust.
* Delivering on Rust's Promise is a cross-cutting theme: Closing the gap between expectation and reality. (You might think it is largely a Developer Experience issue, but a lot of the benefits of closing the gap are actually in enabling the contributors to deliver things like "safety" in the first place.)

There were two big themes for the Improving the Rust Developer Experience: [Debugging][], and [Faster Compiles][].

[Debugging]: #Debugging-Object-Code
[Faster Compiles]: #Faster-Compiles

For the Compiler Contributor Experience, the two big themes I identified were [Librarification][] and [Compiler Backend][] work.

[Librarification]: #Compiler-Librarification
[Compiler Backend]: #Compiler-Backend

For Delivering on Rust's Promise, there are two sets of issues that I would like us to work on making forward progress on: The issues marked [I-unsound][], and the issues marked [P-high][]. In addition, there is ongoing work to improve [Async Rust][].

[I-unsound]: #I-unsound-issues
[P-high]: #P-high-issues
[Async Rust]: #Async-Rust

Various notes and Draft text follows beyond here. But I think the breakdown above captures the bulk of what I'd like to say in the roadmap; the rest is details that still need to be ironed out, but trying to get those details 100% correct in the desired time frame doesn't seem like the right thing to focus on. Instead, better to focus on: 1. Are these the right goals, and 2. Have we established one or more owners for each goal (and is it the correct owner).

----

[toc]

# Pretty Picture

This graph is a loose web of concepts that I tried to extract from what our contributors said in zulip chat, combined with what's in pnkfelix's own head. Some topics are not strictly T-compiler; e.g. unsafe-code-guidelines has a lot of overlap with T-lang (and that is partly why I don't currently mention unsafe-code-guidelines in the [Introduction][] text).

[Introduction]: #Introduction

graph LR
  dx(("Rust Developer Experience"))
  cx(("Compiler Contributor Experience")) 
  prom(("Delivering on Rust's Promise"))
  
  prom --- I-unsound["I-unsound issues"]
  prom --- P-high["P-high issues"]
  prom --- formal-methods
  prom --- coh
  
  librarification --- mir-as-interchange-format ----
  formal-methods((Formal Methods))
   
  coh((Make Language Coherent)) --- move-off-nll-migrate
  dx --- coh


  coh --- cx
  dx --- ucg
  dx --- async((async))
  coh --- trait-system
  coh --- memory-model((memory model))
  memory-model --- ucg
  coh --- ucg((unsafe-code-guidelines))
  dx --- debugging(("debugging (🜁)"))
  async --- generators
  debugging --- async
  debugging --- wg-debugging
  debugging --- debuginfo
  debugging --- debugger-support
  faster-compiles(("faster-compiles (🜂)")) --- incr-performance --- 
  incr-comp((incr-comp)) --- incr-stability

  incr-stability --- better-incr-testing 
  dx --- incr-stability

  dx --- faster-compiles
  faster-compiles --- parallel-compilation
  faster-compiles --- lqd-work
  librarification(("librarification (🜃)")) --- chalk((chalk))
  chalk --- trait-system
  
  compiler-backend(("compiler backend (🜄)")) --- cranelift
  compiler-backend ---- compiler-backend-selection
  dx --- compiler-backend-selection

  compiler-backend-development --- intrinsic-fallback-to-mir
  compiler-backend-development --- compiler-backend
  cx --- compiler-backend-development
  cx --- librarification
  

# Astrology

It might be "cute" to tag the items and categories with corresponding signs from astrology. Its a very flexible system, since things can be divided into two sets (+/-), three sets (modality=cardinal,fixed,mutable), or four sets (element=fire,air,earth,water). But don't fall into same trap pnkfelix did: Figure out the content *first*, and then do the labelling as an afterthought. We aren't going to get *insight* from applying the labels early on, since they are entirely artificial in this context (in pnkfelix's opinion, at least; but he's no astrologer :wink:).

The elements:

Signs | Modality=Cardinal | Modality=Fixed | Modality=Mutable
---------|-----|-----|-----
Element=Fire (🜂) | Aries :aries: (+) | Leo :leo: (+) | Sagittarius :sagittarius: (+) |
Element=Air (🜁) | Libra :libra: (+) | Aquarius :aquarius: (+) | Gemini :gemini: (+) |
Element=Earth (🜃)| Capricorn :capricorn: (-) | Taurus :taurus: (-) | Virgo :virgo: (-) |
Element=Water (🜄)| Cancer :cancer: (-) | Scorpio :scorpius: (-) | Pisces :pisces: (-) |

# Topics

## Compiler Librarification

### The Trait System

* finish large trait system features (lcnr)
* GATs
* const generics
* "potentially marker traits"

### Non-Lexical Liftimes (NLL): move off migrate mode

* more NLL toward stabilization, i.e. turn off migration mode (Aaron Hill)
* blocked on:
* review of Aaron's diagnostic PRs
* "unspecified change related to leak check"
* Aaron Hill has been tasked with updating the status at the top of https://github.com/rust-lang/rust/issues/43234
* There were once open questions for two-phase borrows.
* https://github.com/rust-lang/rust/issues/56254

* aside: pnkfelix isn't certain that this is perfect for this document; it might be a hard space for other people to get involved in. And also, its not clear to pnkfelix how much of this task is to benefit Rust developers, versus whether it is largely to clean things up internally for the benefit for rustc contributors. So it might be miscategorized...

## Coordination

wwiser points out:
> I would love to see if we can find groups of people interested in working on the same things. Even if it's just two people, knowing that someone else is interested in the same thing you are makes it easier to have discussions about the feature, issues, etc and also gives you an obvious reviewer.

# Remaining Notes / Leftovers

* todo: add a bit on ongoing WG-diagnostics work, owned by estebank
* todo: add const-generics/const-eval; has WG as owner. Maybe lcnr; boxy; oli? Also: *where* does it in the doc, as laid out by pnkfelix?
* todo: maybe tag which things are known to be good on-ramping experiences for new-comers? E.g. diagnostics, chalk, cranelift,