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)
We could also defer to next week, since I imagine many people are still on vacation.
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
- maybe, but we have to figure out specifically what
- salsa, polonius, chalk, etc
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:
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.
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.
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?
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.
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?
(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)
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
- or identify some other form of doc coverage metric
- we might also block PRs that lower the doc threshold
- maybe we can set some specific documentation targets? For example, enabling
- 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).
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.
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?
We didn’t really get very far into what that agenda should be. I have definitely been thinking a lot about the RFC / stabilization process, but mostly I guess from the perspective of the lang team. I am very interested in trying to do more “holistic” planning, so that we are not working on language design questions without some idea of who will implement them, and without a rough stabilization plan (I’d like us to work more serially, rather than the current scheme where we just have a series of pipeline stages with unbounded queues that people keep tossing things into willy nilly).
So, definitely a crucial bit for me is the interaction between the lang/compiler team. On the one hand, I think that the “what it ought to do” and “how to do it” are definitely distinct concerns, but of course there is also feedback both ways between them. I think what probably makes sense is that when we are in the implementation stage we kind of have two “tightly coupled” working groups with overlapping members working in concert.
All that said, I wonder if this particular part discussion ought to be had with both lang + compiler team in concert. Interesting question.
I am curious what came out of the all-hands meeting last week. Are there meeting notes or something? Any notable decisions?
We have a steering meeting tomorrow. Here are is an array of possible topics that have come up lately:
- How to integrate “future compatibility warnings” into triage to ensure they “move along” at a more regular pace
- The roles and expectations of “journeypeople” and “full members”
There are also a few things that came up that might fit better as “announcements”, although maybe there is enough to discuss:
- Projects looking for support, are people available?
- Continuing the theme that came up in today’s triage, around who might be available to help the RLS 2.0 effort get underway.
- We’re trying to build an “expert map” showing the various parts of the compiler and who knows about each one in the Meta WG, and would like people to take a look (no link yet, will be coming soon)
Other suggestions, announcements, etc?
Another idea: how to manage the steering meeting agenda more efficiently =)
Something I’d like to have soon is some kind of written-down policy on how handle out-of-tree crates hosted in github/rust-lang. That’s probably a topic for a steering meeting (but doesn’t have to be this one)?
Good suggestion. In our “meta WG” meeting yesterday, @davidtwco volunteered to go over our notes on that topic from the All Hands and create a summary, so maybe we should wait until that is done and we have a good starting point.
I created this HackMd document to accumulate steering meeting discussion topics in between meetings. I’ve added the things from this thread so far.
Also, @mw asked about discussing the policy for out-of-tree compiler crates (expanding on discussions from the All Hands’ organizational meeting), a draft for which was already in-progress by @davidtwco.
The meeting commenced with a call for involvement in the RLS 2.0 working group led by
@matklad as sharing expertise between the RLS 2.0 effort and rustc would be helpful.
There is documentation (videos and guides), issues with
E-mentor and other resources available
for those interested. @davidtwco, @pnkfelix and @Xanewok
mentioned that they would endeavour to find some time to dig into RLS 2.0.
Next, @nikomatsakis announced an ongoing effort by @spastorino to collate an expert map about who has expertise in which areas of the compiler, with the intent of making it easier to find the right people to ask questions and assign issues/PRs to, and invited everyone to help flesh it out and add themselves. @nikomatsakis also suggested that this would be good in documenting the overall structure of the compiler in some ways.
Following this, the main topic for the steering meeting, the out-of-tree crates policy was discussed (for things like polonius, chalk and the upcoming diagnostics refactoring). The current draft of the policy was linked and @davidtwco emphasised that it was very much a draft and there are lots of unresolved questions.
@nikomatsakis highlighted a desire for having a uniform experience between out-of-tree crates and normal in-tree development - particularly surrounding who can land PRs, highfive reviewer assignment, and ensuring anyone in the team can publish new crate versions.
@davidtwco noted that discussions surrounding tooling that could make out-of-tree crates easy to work with was left out of the policy draft as that isn’t part of the policy.
@pnkfelix raised concerns about current policy wording suggesting that only general-purpose functionality should be factored out and suggested clarifications about the minimum bar for expected re-use might be beneficial. @nikomatsakis mused that making libraries too general purpose could carry a higher maintainance/breaking-change burden. @mw suggested that this would need to be decided on a case-by-case basis. @nikomatsakis clarified that we should absolutely be following semver in these crates.
@nikomatsakis then raised the question of review policy in out-of-tree crates - should major PRs require multiple reviewers? can crates have reviewers that are not reviewers of rustc? Going to on say that the idea of these crates having their own communities is appealing and that one option might be that if a contributor was involved in crate sufficiently to review it, then perhaps they should get rustc r+ too or that out-of-tree crates might offer a way to do more fine-grained notions of r+. @pnkfelix suggested that long-term we might want in-tree tests of these crates to guarantee that they maintain compatibility.
@mw then proposed walking through an example - the self-profile working group will likely create a mildly sophisticated on-disk string table that will be shared between rustc and external tooling created by the working group and that this would be an ideal candidate for an out-of-tree crate.
This raised the many questions. Do compiler team members have the rights to create repositories in the rust-lang organization? Is it best to start in the rust-lang organization or prototype in a user-hosted repository? What do we name these crates? Is there guidance on adding crates.io dependencies to rustc?
@davidtwco suggested that we would need to collate a list of things that would need to be added to a repository (licenses, code of conduct, etc.) and things that would need set up (bors, highfive, etc).
@wesleywiser mentioned that while anyone on the compiler team should be able to r+, only those actively involved should be on the highfive rotation. @nikomatsakis noted that it would be great for active working group members to have the opportunity to gain r+.
@mw asked if we would set up community infrastructure (such as Zulip instances or streams) for the out-of-tree crates, but @nikomatsakis thought it best that this be tied to the community infrastructure already in-place for the working group.
Then, @nikomatsakis re-raised the question of whether these out-of-tree crates are best kept in the rust-lang organization. @mw suggested that this is best as it simplifies bors and highfive integration and would use existing team permissions. @pnkfelix asked how challenging migration from a personal repository to the rust-lang organization is. On this point, @nikomatsakis said that transferring is easy but messy - transferring can leave a redirect behind which will conflict with the default name of a fork, which requires an email to GitHub to resolve.
@davidtwco interjected that it should be made clear what team and working group is responsible for any repository we create in the rust-lang organization. @nikomatsakis suggested a template for the README of out-of-tree crates would be valuable and should point to the responsible working group.
Changing gears, @mw asked if there were any example workflows for handling changes in external crates to which @nikomatsakis suggested that a rustc-guide chapter on that and how to make local copies for debugging would be necessary. @davidtwco asked what information should be kept in the policy document and what information should be kept in the rustc-guide. There was some consensus that setting up a new out-of-tree crate is policy and working with one is for the guide.
@mw then raised the question of where consent of compiler team members should be gathered
before creating new out-of-tree crates. @pnkfelix suggested it could be a triage meeting
item and @nikomatsakis suggested using
@rfcbot and that the general presumption
would be that if a compiler team member wanted to create a out-of-tree crate then it would probably
be a good idea. @mw mused that something asynchronous would be preferred and that agreement
within the working group itself should come first. @nikomatsakis suggested that
the goals of approval should be discussed, such as helping to pick a suitable name.
@mw suggested that a list of these crates would be valuable and there was agreement that it should not be in rust-lang/rust to avoid the bors queue. There was some discussion about searching for issues across repositories in an organization.
@davidtwco then agreed to write these minutes and his hands are starting to get tired at this point.
- oli-obk mentions that wg-diagnostics is planning to use the annotate-snippets crate within rustc.
- nikomatsakis is planning, as part of the @WG-meta working group, an RFC that will propose more intermediate levels for the compiler team to recognize committed, regular contributors.
- Zoxc almost has a series of PRs pushing queries all the way back to parsing.
- davidtwco has, after numerous attempts, managed to produce a have a working branch that unblocks RFC 2008.
- pnkfelix applauds oli-obk’s fixmeh project, which lists all the FIXME comments in the compiler.
Our main topic of the day was enumerating the needs of the compiler team:
Can we try to enumerate what are some of things the compiler team needs to be tracking? What communication is (or should) be happening? I’d like us to be able to come up with a good list of all the things we think should be happening, so that we can compare against our existing processes, and try to ensure they are covered (or adjust the processes as needed).
We produced a paper document that contains a pretty comprehensive listing, sorted into categories.
After other topics that came up along the way:
- Ideas for how to have higher-level design meetings
- Thoughts about the “office hours” concept
- What we can do about status updates
- lolbench, the project to measure and track the performance of generated code
- nikomatsakis has opened a PR with a draft RFC on the compiler-team repository. This RFC describes adding a new level (“compiler team contributors”) to recognize people who have been contributing regularly. It also tries to document a few things about members etc. Please give it a read!
- eddyb is nearing completion on their work on the symbol naming revamp. It might even offer some performance improvements.
- nikomatsakis mentioned that in the wg-traits meeting on Monday we plan to discuss how the Chalk crates are setup and the work to refactor them to make them more friendly for the RLS etc.
Our main topic of the day was a proposal to add a regular design meeting:
So this was our plan for the main topic today:
- After that we’ll talk about my proposal for a regular design meeting and perhaps also a bit about working groups and how we feel they are working, what’s could be improved, etc.
The goal of the proposal was to have a central place where the team can review designs and have design discussions. These discussions could have a few forms:
- In some cases, people might bring a thorny problem, looking for help in finding a design. (Example)
- In other cases, people might be bringing an existing idea for evaluation and broader discussion, looking to reach a conclusion. (Example)
In each case, there will be a proposal describing the question at hand and the goals of the meeting. The expectations for this proposal would vary depending on the kind of discussion. For “early stage” discussions, the proposal might be fairly sparse. (Perhaps like this example.) For meetings that aim to reach firm decisions, the proposals would be expected to contain more details; it would be useful to list things the author expects are hard to do and also points where there are design decisions to be made.
The expectation is that these meetings will help us propagate knowledge of what is going on through the project; they will help people get feedback on designs (right now, it can be hard to get people to make time to really talk out a design). Finally, they can help newcomers to get more familiar with things, since people can lurk in the meetings and soak up details (not to mention the paper trail).
While the basic idea of the proposal was popular, we wound up changing some of the details for how it would run. We settled ultimately on reusing the slot for the existing steering meeting (Friday mornings, Boston time) but making it weekly.
Every Nth meeting (likely 3 or 6) would be a designated steering meeting. The role of these steering meetings it so select the next N-1 topics that will be discussed (from a list of proposals). In between meetings, people can add meeting proposals to the list for the next round.
When we make these decisions, we would be trying to take a “global view”. In particular, we don’t want to be doing designs unless there are people who will put them into practice. This probably means that we will prioritize design questions arising from existing working groups, but we might also take up design questions that might become the basis for a new working group, as long as there are people who would want to take part.
We also spent some time discussing the idea of a mentoring or ‘internship’ program for helping “frequent contributors” make the jump to “compiler team member”. The designs that we discuss in this meeting would hopefully wind up detailed enough that frequent contributors can pick them up and implement them, even if the people making the design are busy with other things. Similarly, design documents can become the basis for rustc-guide chapters.