2019 Roadmap Progress?

internals
1

The roadmap this year outlines a theme of finishing what we started and paying down tech debt. I'm wondering what people have been working on and how much progress has been made on this roadmap. Are there concrete goals we have accomplished? Is there something we can celebrate? Is there something we should push harder on?

22 Likes
2

rust-analyzer is mostly the opposite of "finishing what we started" implementation-wise, but it fits in the overall "maturity of tooling" theme. The biggest thing that happened is that we proved that it is possible to expand macros and solve traits to provide correct instant completions for Rust, in principle (:tada:).

So far, this was mostly an independent of rustc experiment, but now I think we should push harder on making rustc work along the lines of rust-analyzer. I am proud of the first step in this direction: rust-analyzer and rustc now actually share the same lexer. Now we only need to split the rest of the compiler into libraries :rofl:

43 Likes
3

Great idea to check in!

I suppose the other obvious one is async/await. With std::future stabilized in 1.36 and .await coming in 1.39, a lot of progress has been made. On the other hand, it's pretty far from being "finished"; there will still be async trait methods, streams and async closures to design and/or implement.

For reference: Rust's 2019 roadmap blog post and RFC 2657.

15 Likes
4

This sounds like an interesting exercise. Here's an update on the Cargo team. Apologies if it is too long/verbose.

  • Cross-compilation
    • The first PR for std-aware cargo should land within a few days. There is still a long road ahead, but I'm pleased with getting this first step.
  • Plugins
    • Unfortunately there has not been significant progress on this. About the only progress is small additions to cargo metadata to make it more powerful (such as this upcoming change). There are also plans to separate "platform" parsing to go along with this.
    • Since there isn't anyone championing any other parts of this story, it is unlikely to make significant progress this year.
  • Compile times
    • Pipelining is now enabled, which should land in 1.38.
    • Supporting multiple target directories is a bit blocked right now on reorganizing some parts of the target directory. Multiple target directories would allow you to have a shared global cache between projects. There are two PRs (6577 and 6668) laying the groundwork, but work has stalled a bit. Some work needs to be invested to figure out how to not break most tools and projects. I plan on reviving this very soon. This is also blocked by having some kind of story for better cache management, which was recently summarized here.
    • I do not think there has been any progress on pre-built binaries, and I think is unlikely this year.
    • HTTP/2 multiplexing hit stable 1.32 in January.
  • Documentation
    • Man pages were all rewritten and are now published online in 1.33.
    • A glossary was added in 1.32.
    • A changelog is now being kept.
    • There hasn't been much focused effort on improving documentation. I have some moderate things I want to do (such as separate chapters on the resolver, workspaces, profiles, and features), but haven't really started.
  • Features
    • I have recently revived design work on improving features, but there is a long road ahead. One of the greatest challenges has been trying to decide how to deal with backwards compatibility, since several enhancements are in direct opposition of how the current system works.
    • 7216 lays some basic groundwork needed to better track features within the compilation graph.
  • Profiles
    • Named profiles is underway.
    • Build profiles has a PR, but it is stalled. I hope to resume it this year. It is blocked on target directory reorganization.
    • I'm delaying stabilization of other profile enhancements until named profiles is closer to finished. I've also discovered some issues with profile overrides that concerns me.
  • Other
    • Alternate registry support was stabilized in 1.34.
    • Offline support was stabilized in 1.36.
    • cargo vendor was moved into cargo in 1.37.
    • published lockfiles was stabilized in 1.37.
    • default-run was stabilized in 1.37.
    • Pre-publish verification has not made significant progress this year, AFAIK. There is a summary of validation, but it really needs a new publish web API.
    • More than 300 PRs have been merged this year so far. Many performance improvements, fixes, and small changes, this list is already too long!
  • New, unstable features added:
51 Likes
5

This blog post has data on the quite significant compilation speed improvements between January 1st and July 24th.

8 Likes
7

[Sorry I fat-fingered the post button before finishing]

We did not seem to get much feedback from the compiler team beyond nnethercote's post (which is awesome and much needed btw), but here are some things I have picked up via lurking:

  • Infra:

  • Parsing and lexing:

  • Macros:

    • petrochenkov been steadily reducing technical debt, with lots of progress made on unifying proc_macros and macro_rules and on hygiene

  • Type system:

    • Const generics is making steady progress: report
    • Niko is working on lazy normalization and universes, which should unblock a ton of other stuff: https://github.com/rust-lang/rust/pull/65232
    • Chalk made a lot of progress earlier, and it seems that effort is being redoubled now

  • Borrow checker

  • MIR

    • Many refactorings have happened here that will enable more powerful analyses and more MIR optimizations later (e.g. Place 2.0). I'm not sure of all the details here, but better MIR optimization means we give LLVM better IR, which means faster codegen

  • Const eval

    • A new dataflow framework is currently in progress that will enable more things in const fns.

  • Codegen

    • Now using LLVM 9. I believe this includes a bunch of fixes that make it possible for us to communicate more info to LLVM. Not really sure of the details though

  • Parallel compilation

    • A lot of auditing and code review has happened here, and a plan has been roughly established for moving forward in a data-driven manner. There is still a long road ahead, but progress is being made, especially in the form of refactorings and design meetings

  • async/await MVP is shipping in November: https://blog.rust-lang.org/inside-rust/2019/10/07/AsyncAwait-WG-Focus-Issues.html

  • There have been a ton of other things (way too many to remember)

    • most of the working groups seem to be making some sort of progress
    • Tons of bugs fixed and lots of tech debt paid down.
    • miri continues to make progress and is becoming a useful tool for checking soundness of unsafe code
    • rust-analyzer continues to make progress including the integration of chalk and making macros work (roughly)
    • several design meetings (which you can find on zulip)
    • the Inside Rust blog started: https://blog.rust-lang.org/inside-rust/
42 Likes
8

And this follow-up blog post has data on more compilation speed improvements between July 23 and October 9.

2 Likes
9

Thanks for the update. As I am translating MIR to SPIR-V, is there a WG (or similar) that I can follow to stay ahead of the breaking changes?

1 Like
10

Hmmm.... not sure. Maybe be WG-mir-opt? @oli-obk or @spastorino might know better

11

Yeah I think @mark-i-m is right WG-mir-opt and maybe WG-nll but I don't think changes to the MIR are happening from WG-nll anymore. There's also WG-polonius which you could check it out too just in case something comes up from of there.

1 Like
12

A related question: Now that it is almost November, should we start soliciting 2020 roadmap posts in order to actually have a roadmap at the beginning of 2020?

10 Likes
13

We will be doing that shortly.

6 Likes
14
2 Likes
15

I'm curious if anyone can give an update on the status of Chalk (perhaps @scalexm or @nikomatsakis)?

Specifically, it seems that the trait system needs a lot of love, and I lot of bugs have come from either our lack of understanding of the current trait system or from bugs in the implementation (see for example https://github.com/rust-lang/rust/issues/57893 or Unsoundness in `Pin`). It seems like these sorts of bugs could have major disruptive impact on the rust ecosystem if we are not careful...

2 Likes
16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.