Roadmap 2020

Roadmap 2020 Compiler Discussion

Zulip topic

2019 roadmap (for reference)

The compiler team has five main themes of work for this year:

  • Improving “core strength” by lowering raw compilation times and also generating better code (which in turn can help with compilation times)
  • Improved IDE integration, including support for typed completions
  • Extracting parts of rustc into libraries, which are easier to understand and maintain but also help in developing a Rust specification
  • Supporting lang team in key feature development, such as around async fn support, or improvements to the trait system
  • Improving our documentation and organization, helping to make it clearer what is going on at any given time, and how people can get involved.

Big challenges for rustc and compiler team

Poll to vote – feel free to add your own items to the poll; you can also add notes below with a few lines of elaboration.

  • compilation times remain stubbornly high
    • many companies have huge codebases and compilation time can be an existential crisis
    • we feel this ourselves with bootstrapping
      • band-aids like “factor librustc into finer grain crates” might work; cannot be “official answer”
    • incremental has helped but it’s not like a 1-line change is ‘instantaneous’
    • this bullet is talking about the time it takes to “run tests” and do full builds; it does NOT refer to the “instantaneous feedback” for things like completion, which falls under IDE
  • tech debt around the trait system
    • blocking a lot of lang team progress (async fn in traits, GATs, specialization)
    • “lazy normalization”
      • also maybe blocking const generics work
      • also support for higher-ranked lifetimes etc remains a common place where you can hit ICEs that have no real fix
    • possibly performance impact
  • maintenance and triage work
    • we do a decent job of keeping up with work but work burden is unevenly distributed
    • non-urgent / non-regression bugs can “pile up” – are we making progress on them?
    • (note absence of data here; maybe we are keeping up, relative to bug-report rate and/or bugs that actually matter…)
      • (simulacrum): we are not really keeping up
      • long-term trend is up; most current issues are fairly recently triaged, count has been going up: ~3000 last summer, up to 4900 now. Not all compiler team, but “most”.
  • IDE story is confusing, we’re not focusing our efforts
    • we need a strong IDE story
  • new features draw in new volunteers more easily than maintenance/paying-down-debt
    • can we make such work more exciting? E.g. via gamification?
  • documentation and design
    • many parts of the compiler remain undocumented
      • writing mentoring instructions often requires recounting same details over and over
    • we have a lot of great design ideas but there are often ill-documented
    • ambitious rewrites can be hard to review without knowing ‘the plan’
      • also, often it’s not clear how much consensus there is on the plan
  • paying for labor
    • we rely on volunteers for vast majority of coding effort
    • some of this is coding done while “on the clock” for some boss, with that boss’s blessing
    • (there are also contract laborers, financed by companies with specific needs)
    • is this model of compensation going to suffice going forward?
  • team growth
    • Find more people to help out
    • Improve the onboarding process
    • Mentoring/help

Discussion summaries

compilation times

  • benchmark vs end-user programs
    • maybe set a strict goal of improving bootstrap times (link)
    • rough conclusions
      • bootstrap is worth focusing on
      • codegen time is a big deal
    • incremental could be improved, e.g. measure/improve the “edit comment” use case
      • tracked by rust-lang/rust#47389
      • eddyb writes:
        • don’t do any work past the HIR when only a comment changed (targeted Span improvements may help)
      • move incremental back so you don’t need to spend entire seconds getting to HIR

trait system

  • made progress this year but not as much as hoped
  • conclusion:
    • we need most of all a clear roadmap here, and that should be an immediate focus
    • good to try and separate out lazy normalization from other goals

See also