Compiler "Steering Meeting"

[michaelwoerister]

I think that’s a good plan. A diagram like that is good for identifying independent task and possible interactions between seemingly independent tasks.

• I think it would make sense for each major topic to be discussed and plan in some detail before the All Hands, that is, at least each topic that we might want to make implementation decisions for.
• It would also be good to have a shepherd (team of shepherds) for each topic (or SCC in the diagram).
• We should also have a table that shows for each area (1) the expected benefits and (2) the projected, transitive implementation cost. That should help with prioritization.

[nikomatsakis]

It would also be good to have a shepherd (team of shepherds) for each topic (or SCC in the diagram).

Yes, this.

[nikomatsakis]

Let me back up and just give a few thoughts about burnout and stress. I want to get to a place where we have, for each major initiative, one or two leaders. I also want those leaders not to be pushing on more than one big thing at a time, at least not as the primary leader. Speaking as someone who often finds themselves trying to push through a bunch of ideas at once, this involves a bit of stepping back. This is not always easy. But I think it’s crucial to growing the project and to avoiding burnout on the part of those of us who are heavily involved.

Keeping this rule in mind will put some limits on our ambitions. We can’t do everything, at least not at first. But that’s good and realistic, I think.

To use myself as an example, I think I would like to focus on the chalk transition and trait system overhaul (with @scalexm as a co-leader).

But then there is a tension: I’m not sure how to reconcile that with the Polonius and borrow checker work, which I also think is important. I would love it if we somebody else can step up as the “primary driver” for that work, and I can try to stay involved from a distance. (Or maybe it should just wait, which might be ok anyway, because to some extent it’s all blocked on enabling NLL for 2015 and so forth, and we just have to give time for that.)

(A separate question is whether Chalk is a good area to focus on. I continue to think it is, both because of the number of things that it unlocks, and because I think there is good potential for compilation time speedups. I also think that separating out and cleaning up the trait system will pay off in terms of aiding the RLS.)

[nikomatsakis]

Something else that is not represented on the diagram, but which I think is important, is figuring out how to manage the RLS and the rust-analyzer project. I continue to see promise in @matklad’s (and others’) attempts to design an interactive IDE experience from the ground up. OTOH, I continue to be concerned about supporting two compilers, and I recognize the value of a more incremental (no pun intended) approach.

I think in my ideal world we would focus on finding places we can cooperate: e.g., on paying down technical debt by refactoring name resolution and type-checking out of the compiler into a cleaner, more abstract codebase that can be shared. It’s not clear how to prioritize or enable that work though.

This ties in with more general questions of how to manage the compiler. I have to make sure that is on the list of All Hands questions. (Update: it is)

[Centril]

To use myself as an example, I think I would like to focus on the chalk transition and trait system overhaul (with @scalexm as a co-leader).

Personally I think Chalk is super important because GATs are probably by far the most important lang feature in the pipeline so I would encourage what you said.

OTOH, I continue to be concerned about supporting two compilers, and I recognize the value of a more incremental (no pun intended) approach.

(This also gets into questions about which compiler is authoritative and that we, very-long-term, might want a formal semantics encoded in Agda/Coq/Lean/Random-Theorem-Prover that is then authoritative)

[michaelwoerister]

Let me back up and just give a few thoughts about burnout and stress. I want to get to a place where we have, for each major initiative, one or two leaders. I also want those leaders not to be pushing on more than one big thing at a time, at least not as the primary leader.

Seconded. I personally don’t do my best work when I’m spread out too much and in a leading position, having too much on one’s plate can quickly affect one’s well-being. This is one reason why I like the idea of having a team of leads, each member of which basically shares the same responsibilities. It can also make a big difference if you have a go-to person for quickly bouncing ideas off of.

[michaelwoerister]

We should also have a table that shows for each area (1) the expected benefits and (2) the projected, transitive implementation cost. That should help with prioritization.

I added an initial version of such a table to the brainstorming document: https://hackmd.io/Wbnday_dQxSy-iPWLm33Rg?view#Table-of-possible-projects-with-some-analysis (unfortunately it’s too wide for hackmd…)

UPDATE: It’s actually easier to read in edit mode

[nikomatsakis]

2018-11-16

We had our second steering meeting today. We drilled into some of our plans for the future, and specifically into some ideas around batch compilation. You can find the meeting minutes over on the new compiler-team repository, which will hopefully become the home for “all things compiler team” over the fullness of time. =)

Some action items that I think I would like to get help with:

• take another stab at collecting and organizing ideas, incorporating ideas around UX in particular, but also breaking out RLS from batch compilation (nikomatsakis)
• gather statistics about where we spend our time from perf and perhaps elsewhere (?)
• draw up a proposal for polymorphization analysis / strategy (maybe nikomatsakis?)
• collecting some numbers on how parallel queries performs these days (mw)
• draw the graph of refactor dependencies (eddyb/nikomatsakis, perhaps?)

[djc]

I just want to say, even though I unfortunately don’t have time to participate in compiler stuff much, I think the way you’re working in the open on internals.r-l.o and sharing what’s going on in the team is really great. I hope more teams and/or working groups will adopt your style over time.

[nikomatsakis]

Given that there is the Mozilla All Hands this week, which has @michaelwoerister and I tied up, I propose that we postpone the steering meeting this week by 1 week (until Dec 14). I further propose that we also postpone the next steering meeting by 1 week until Jan 4 (because otherwise it would be on Dec 28, which is a holiday for many folks).

If there are no objections, I’ll adjust the calendar events. =)

[nikomatsakis]

2018.12.14

(These minutes are also available on the compiler-team repository.).

The steering meeting was focused on mentoring. Some of the prompting questions:

• How can we help move people from “working group participant” to “full-fledged team member”?
• How can we reduce the “bus factor” for cricial modules like the type checker, type resolver, etc?

A summary of the major points raised follows. If you prefer, you can read the full transcript on Zulip.

Major points: Mentoring

• it seems good to try and list out the parts of the compiler and who is an expert in each one, perhaps in some kind of “introduction to the compiler team” page on the repository
  • this can help identify where to direct your questions about code X
  • but also where we need to increase the number of knowledgable people
• it would be great if we had an organized off-ramp system for folks who have been active in a working group and are looking to broaden their knowledge
  • maybe we can pair up such folks with someone more experienced
  • this is a different sort of mentoring, since active people from a WG are already familiar with how the compiler works, and thus able to work at a higher level
  • we need to find a way to make it easier to find “intermediate-level mentoring opportunities”.
• we might try to actively increase bus factor via fixing issues, writing tests, or writing docs
  • writing tests can be driven via code coverage measurements
  • writing docs can be driven via deny(missing_docs) as well as push to complete the missing rustc-guide sections
  • one problem with writing documentation is that there always seems to be something that is higher priority, maybe implying we need it as a roadmap item
• a dedicated #t-compiler/help stream would be a good way to call attention and request mentoring
  • maybe other streams as needed
  • also, documentation on how to use zulip seems like a win

Major points: process for refactorings, documentation

Towards the end, we also discussed the procedure we should use for larger compiler refactorings as well as how to ensure the compiler is documented.

• before landing a massive refactoring or new architecture:
  • ideally, talk out the design on an internals thread to achieve some light consensus
  • expect documentation in the form of rustc-guide chapters
• some examples where we should do this:
  • end-to-end queries
  • parallel query execution
• in terms of the rustc-guide:
  • it’d be great to improve mdbook to permit for graphs
    • maybe we can add graphviz support into mdbook
  • we should not neglect doc comments
    • and we can link back and forth copiously (and make sure we check for dead links)

[nikomatsakis]

Question: Do we want to have a meeting tomorrow? Will people be around? I’ve not really done much prep for it – I think we should probably however start talking about the upcoming Rust All Hands in a bit more detail, so maybe it makes sense to start that conversation tomorrow (i.e., try to figure out what would be the best meetings to have, etc)

[nikomatsakis]

We could also defer to next week, since I imagine many people are still on vacation.

[nikomatsakis]

2019.01.04

Zulip topic

These minutes are also available on the compiler-team repository.

We discussed the upcoming Rust All Hands. We have a HackMd document that lists a bunch of ideas for what to talk about, but mostly we talked about how to structure the meeting itself.

We summarized how the All Hands was structured last year: basically meetings focused around particular topics, with the team (and others) mostly in a kind of semi-circle or around a whiteboard.

One of the ideas we had for this year is that we could have some sessions that are just focused on explaining how a particular area of the code works, which could help people unfamiliar with an area get up to speed.

In general, we decided that each of our slots should begin with some exposition of “how things work now”, and then segway into “here are problems to resolve”. We will try to take good notes on these expositions as well.

We discussed how it might also be useful to talk about some of the tools that are “adjacent” to the compiler, e.g., rustdoc or RLS.

We discussed some possibler areas for discussion:

• the rustc-guide
• related work, like RLS, rustdoc, or cranelift
• mentoring?
  • maybe, but we have to figure out specifically what
• salsa, polonius, chalk, etc
• diagnostics

On the topic of IDEs, it would be useful to hear from Matklad about rust-analyzer.

We also thought a bit about some more “radical” ideas that might be worth making a bit more concrete:

• downloading pre-compiled artifacts
• compiling all configurations at once for docs, IDE

[nikomatsakis]

Reminder that tomorrow is another steering meeting. I’d like to hear thoughts about a “theme”. Here are some thoughts:

• How to do maintenance and issue triage better (we discussed this some today).
• All Hands schedule – I have a kind of “semi-draft” for this I can post and we could discuss overall structure.

[nikomatsakis]

Some stream of consciousness thought about these issues I raised above follows. I apologize for the length. I’m going to try to post a follow-up comment here that digests these things, but I figured I might as well post this too.

How to do maintenance and issue triage better (we discussed this some today).

Some of the problems we were talking about:

• We are pretty good at tackling regressions and P-high things, but what about the backlog of random ICEs or other P-medium issues?
  • Can we and/or should we try to systematically attack those?
• Can we save some time at the triage meetings somehow to make a bit of time for that?

• All Hands schedule – I have a kind of “semi-draft” for this I can post and we could discuss overall structure.

Honestly, it’s still pretty hard to figure out just how much time we’ll have for dedicated meetings etc. But I think that if we could come away from this meeting with a sense of which are the most important conversations to have, that would be very helpful.

To my mind, the main goal of the All Hands should be us to establish a strategy for “rustc in 2021” – actually the problem may be bigger than rustc itself, since I think we should really also be considering IDE support, and that may imply some interaction with cargo etc. But basically what overall compilation architecture we are shooting for in the next edition.

Looking over the HackMd document, my sense is that the single most important discussion to have is this one:

• Consensus on IDE Integration
  • what is our “end goal” – how do we envision the interaction of rustc, IDE, cargo to be in “2021”?
  • what are the steps to get there?
  • how can we get more interaction between rustc team and RLS maintenance?

In order to even have that conversation, though, I think it would be pretty useful to get reviews of how things are working today. For example, I would love to get a brief overview from @Xanewok on how the RLS is setup, and similarly I would like to hear from @matklad about rust-analyzer – the experiments that @jntrnr, @wycats and I have been doing on Lark are relevant, but I’m not sure if it makes sense to present about them specifically.

The above conversation (IDE integration) also touches on a number of other issues I think are relevant and potentially worth talking out:

• end-to-end query architecture
  • I think what I mean by this is: given the goal we established in prior conversation, what are the steps we take to get there from here (how compiler works today)
• integrating submodules and libraries
  • I would like to see rustc start to take a page from Servo and try to break itself up into more independent libraries. Things like chalk and polonius, yes, but perhaps for the type system, MIR transformations, etc.
  • Managing these as separate repositories has advantages: less bors time, etc. But it has costs: harder to coordinate changes, issue triage is hard to manage. What should we do?

Looking beyond the IDE a bit, and perhaps with a slightly more narrow scope, I think our biggest priorities are going to be:

• Parallel compilation: More cores, more speed. What’s not to like.
• Improved incremental support: Now that we have the incremental infrastructure, we need to dig into more scenarios and see why some of them aren’t paying off. Also, what can we do to optimize the implementation itself, such as faster serialization, deserialization, etc?
• MIR optimizations: We need to set some specific goals, but there are improvements to generated code (fewer memcopies) that can be important, and I think things like MIR-based inlining may also be helpful for reducing time spent in LLVM.
• Chalk integration: hopefully improves performance, unlocks GATs and some other more advanced features, hopefully fixes a bunch of bugs.

Of these, I think that MIR optimizations could most benefit from some focused group discussion. I can see various interactions. For example, @eddyb had proposed some changes to how MIR is setup to make it easier to perform optimizations, and it’d be great to go over the optimizations we think we might want to do and try to sketch out interactions with stacked borrows (cc @RalfJung) etc.

Chalk integration too has a fair amount of open questions, and it would be interesting to prepare and go over a lot of the details and try to map out some of the challenges we will hit.

Looking beyond the technical, I think the main thing I would want to talk about is reforming our structure a bit and specifically creating an apprenticeship pathway. For example, I would like to have the steering meetings start to transition to regular check-ins (perhaps in a round-robin fashion) with the various active working groups, getting an update on how things are going etc. Questions like triage and ice-breaking are relevant here too.

So my questions for the group might be:

• Does that list seem like a reasonable set of priorities?
  • Should something on it be removed or replaced?
• There is lots of work missing from that list – e.g., finishing NLL transition. Are there discussions to be had about that?
• What about technical topics and reviews? I am now thinking that maybe it’s more realistic to do those as part of the lecture series, but I guess it depends on how much time we have.

[nikomatsakis]

To try and coallesce some of what I wrote above:

Major goal for All Hands

Find answer to the question, “What does rustc + IDE integration look like in 2021?” and chart a course to get there, including specific goals for 2019. Relate this design to the key problems we are trying to tackle and (bonus points) discuss some benchmarks we can use to track our improvements.

Key conversations to have

I think my list of key conversations to have is something like this. This is only semi-ordered. I’d be curious to know if people think there are conversations that I am missing, and also what relative order you might place on them. In some cases, some of these conversations could perhaps be “conjoined” into one session.

I don’t know how much time we’ll have to get to these conversations. We may not have enough slots. This is why the relative priority is important – going into the scheduling, it’d be great to have a feeling for which conversations we think are most important, and perhaps back-up plans for those we don’t get to.

• Consensus on RLS strategy going forward
  • How will we support/maintain RLS?
  • Should we adopt rust-analyzer approach? Can we share code with it?
  • One thing that @pnkfelix, @michaelwoerister and I were thinking is that it might be nice to have some “how things work today” reviews first, covering the RLS + rust-analyzer, and then have this conversation on the next day, once we’ve had some time to think those things over.
• rustdoc integration
  • I know that @QuietMisdreavus wanted to discuss the relationship of rustdoc to the compiler. This feels strongly related to, but potentially distinct from, the RLS.
  • There are also some technical topics like how to generate docs for “all configurations at once” (maybe others?)
• Major goals for 2019
  • What will be the immediate steps? Should we make a working group for each one?
• Compiler team governance and apprenticeship
  • How should we organize ourselves and track progress?
  • Do we want to have a plan re: design documents and the like?
  • Can we do more to help apprentice-level folks move towards expertise?
  • Maybe touch on other mentorship topics, like lecture series, rustc-guide, etc
• MIR optimizations and MIR 2.0
  • interacts with borrow checker, stacked borrows
• Type-checking pathway: Chalk + NLL + fate of the HIR type checker
  • discuss the strategy and some of the obstacles we anticipate
  • maybe discuss things like how to rewrite type checker and inference?
• How should the compiler’s code be structured?
  • Do we want more crates? How to manage?

[QuietMisdreavus]

There are also some technical topics like how to generate docs for “all configurations at once” (maybe others?)

(spoiler: there are a handful of other wishlist items i’ve sketched out for our current/planned features, that i want to coordinate with compiler/other teams - https://gist.github.com/QuietMisdreavus/391a611779ac893ad990a599b3a728e5 - i’m eventually looking for guidance on how to make these work or to find alternatives that work better within the compiler)

[nikomatsakis]

2019.01.17

As always, these minutes are also available on the compiler-team repository.

Zulip topic

We discussed the upcoming Rust All Hands.

One of the first things we focused on is trying to get consensus about what the P1 Problems are that we are aiming to tackle. Our goal is to have this list complete before the all hands. Our initial list looked like this:

• compilation time
  • better compilation time investigation tools/analysis
  • this should work in cooperation with cargo, so we can see whole story
• rls, completions
• “too hard to do anything” — technical debt
• “too hard to find people to do things” — organizational debt
  • hard to learn, monolithic architecture
  • poorly documented
  • long compilation times, memory requirements

Looking at it, we realized a few things:

• in past meetings, we’ve discussed how it feels hard to justify time spent writing docs. In general, we felt we needed some form of concrete incentive, similar to how performance optimization gets you that nice green bar. To that end we talked about:
  • maybe we can set some specific documentation targets? For example, enabling deny(missing_docs) by summer.
  • or identify some other form of doc coverage metric
  • we might also block PRs that lower the doc threshold
• in general, this seemed like a good topic to revist under a “compiler team governance and apprenticeship” meeting at all hands

In terms of the all hands, one idea for a possible outcome is to try and produce a “slew of technical design RFCs”, at least for certain key areas (e.g., the so-called MIR 2.0). We later softened this to a “technical outline plus a plan for who writes the full text”, where a “plan” includes who will do what.

One possibility is having “breakout sessions” where a smaller set of people go off to focus on some questions and then bring the results back to the group. It’s not clear how or if this will fit in the schedule.

We then turned to the topic of the RLS. Initially, we were contemplating starting out with some “review sessions”, but we ultimately decided to try and produce that material before the all hands. Ideally, for all of our major meetings, we’d have some kind of review material to get people in sync. Offline material can be enjoyed by others, and it’s nice for people to be able to review it at their liesure.

When it comes to the RLS, we decided to take a “tech first” approach – basically focus on the technical design we want, and then talk about the best way to get it (e.g., improve RLS in place, start over a la rust-analyzer, etc). matklad, xanework, and nikomatsakis held a separate discussion to settle on an initial agenda (topic).

For the “second most important topic”, we settled on “organizational questions”. The “root goal” of any organizational alternatives would be:

• be intentional about what we are doing: make sure we are making progress on the problems we think are most important
• grow the team
• maintain/increase quality

Some sample agenda items were how to handle factoring of compiler into libraries and how it relates to team structure. There was a consensus that having more focused subteams would reflect the reality that the compiler is too complex for one human to fully understand (unless they are eddyb).

Concluding comment:

I feel like we made some good progress on the concept of how to approach IDE discusson.:

• We will start by elaborating technical design and let that guide us the rest of the way.
• We will have some review materials available before the all hands
• We will have a short meeting (like, nowish) to try and create agenda

it seems like we consider organizational matters the next most important thing to discuss as a group. I feel a bit less clear on what the “agenda” will be, but maybe we’ll feel our way, or else maybe we should have some more pre-discussion about it. I would at least be up for trying to prepare a kind of straw-person proposal.

[mark-i-m]

I find it interesting that among the organizational issues, there is not mention of RFC/stabilization processes. Is this something the team does not feel needs discussion? Or was it a matter of time?