As several of you know, I managed to successfully create a proof-of-concept Rust REPL about a couple of months ago. This necessitated (at least, given a clean and sane approach) a few — essentially minor — changes to rustc.

As discussed with @nikomatsakis and @Mark-Simulacrum, the we thought the best way to proceed with this would be to create a design document that summarises my approach to creating the REPL, along with some technical details. The idea is to get some feedback either before or during the FCP process, from which I can proceed by submitting PRs.

HackMD Document

See the first REPL-related PR (currently pending this issue and FCP) for more examples of the sorts of changes I am making (although that will need to be updated somewhat).

Building on the compiler-team contributor RFC, we wish to propose an active mentorship / internship program. This would be a way for contributors to work closely with a member on some non-complex task, helping them to become full members.

Some rough notes:

• this is the final step before being added to the team. A member-in-training generally works with a compiler team member on some notable project. This might be coding work but it could be more organization or design-oriented. The project should demonstrate a deep understanding of some area of the compiler, but it need not be “new feature work” — refactorings etc would also make sense.
  • The member and project should be proposed beforehand to the team.
  • The member-in-training would be committing to work on the project, and the mentor is committing to meet with them regularly and play some part.

In recent PRs to create working groups, the check-in schedule hasn't been updated in initially, this is because we've not documented that step.

Meeting proposal info

• Title: major changes proposal
• Type: non-technical
• Proposed by: nikomatsakis
• Link: TBD
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

Summary

Propose a plan for how one goes about making "major changes" to a compiler area. Outline would be:

• Announce your intentions at a meeting, ideally with some rough sketch
• Identify reviewer
• Document plans and get discussion / sign-off (possibly but not necessarily at design meeting)
• Documentation guidelines

More detailed proposal available here

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

In our recent steering meeting, we made a decision to try and institute a design meeting. There is now some work to get ready for that.

Meeting schedule

@michaelwoerister and I proposed a 4 week cycle with this general shape:

• Week 1 -- Scheduling meeting
• Week 2 -- Design meeting 1
• Week 3 -- Design meeting 2
• Week 4 -- Steering meeting (non-technical discussion)

The scheduling meeting would be used to decide the topics of the remaining 3 meetings.

work items

• the compiler-team calendar needs to be updated to help us track the schedule
• we need a template for meeting proposals (nothing complex)
• we need a place to put those proposals (I propose we put them as PRs against this repository?)
• ultimately, we should have an RFC describing the change

• we need a guide that helps people to get started with this sort of bug -- see rust-lang/rustc-dev-guide#452
• we need some mechanism to make a github team people can subscribe to (as discussed here) -- @spastorino
• we need an announcement (maybe for the new team blog I am setting up!) -- draft blog post in this hackmd doc
• sample PR for adding yourself rust-lang/team#140
• we need a github label -- done, ICEBreaker-LLVM
• we need to update our compiler-team page to drive attention to these groups as a way to contribute
• and maybe think about the main contribution page?
• create a triagebot.toml file in rust-lang/rust (sample) rust-lang/rust#65508
• we need a script people can copy/paste or -- better -- we need some command we can issue the triagebot. This fits with the discussion around "self-subscribing teams". rust-lang/rustc-dev-guide#463 -- @spastorino
• compiler twitter account that tweets these things out

That bot would assign the label and write something like:

Hey LLVM icebreakers! This bug has been identified as a good
"LLVM ice-breaking candidate". In case it's useful, here are some
[general instructions] for tackling these sorts of bugs. Maybe take a look?

cc @foo @bar @baz ...

RFC 2689 created the concept of compiler-team contributors. We need to "activate" that work:

• Update team repository rust-lang/team#66
• Update github teams
• Add material and definitions to this repository
• Blog post

Meeting proposal info

• Title: working group review
• Type: non-technical
• Proposed by: nikomatsakis
• Link: TBD, but see below
• Scheduled dates for discussion:
  • Nov 15, 2019; Calendar event

Summary

The basic idea is to talk about the working group system we adopted earlier this year. How's it working out? Thoughts, concerns? I think before the meeting we would do a survey to take the general temperature, and during the meeting we'd shape the agenda based on the results of that meeting.

Some topics we might look at:

• Is sharing the wg updates with triage meeting good?
• Can we rename working groups to avoid confusing with domain working groups like embedded? (The embedded wg has proposed the term "Projects", for example.)
• How to manage working group membership?

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

The expert map is in machine-readable form (thanks @spastorino!) but we need to fill in the directory information.

Meeting proposal info

• Title: Constitutional Convention
• Type: non-technical
• Proposed by: pnkfelix
• Link: https://gist.github.com/pnkfelix/be11b325cb51a98d3bf67e19d3b7fff5
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

See for example:

but if you manually change your url to one of the missing entries like the following week's, the page is there:

https://rust-lang.github.io/compiler-team/minutes/triage-meeting/2019-06-27/

Meeting proposal info

• Title: RFC: Format the rust-lang/rust repository
• Type: it's complicated
• Proposed by: @Centril
• Link: Centril/rfcs#21
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Meeting proposal info

• Title: compile time analysis and assistance
• Type: non-technical
• Proposed by: @nikomatsakis
• Link: hackmd
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Check list of things to do:

• Create a Github label ICEBreaker-Cleanup-Crew done
• Write a guide advising people on how to bisect-and-reduce and giving some high-level guidelines: rust-lang/rustc-dev-guide#556
• Configure the rust-lang/rust repository to support the ICE-breakers commands, similar to this
• Create the cleanup crew toml file in team repo rust-lang/team#214
• Create a sample PR for adding yourself, similar to rust-lang/team#140
• Link to the sample PR in this section of the rustc-guide
• Write an announcement blog post

WG-traits does not list WG leaders.

See https://rust-lang.github.io/compiler-team/working-groups/traits/#traits-working-group

It probably deviates from the standard template in other ways too.

We have this rust-lang/rust#54818, it may be good to update it and shape it up and move it into https://github.com/rust-lang/compiler-team/tree/master/content/procedures.

Meeting proposal info

• Title: Target tier policy
• Type: non-technical
• Proposed by: @joshtriplett
• Link: https://gist.github.com/joshtriplett/40191791541ea2a3d61b7fe1d381a0e7
• Scheduled dates for discussion: 2019-09-20

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Meeting proposal info

• Title: roadmap 2020 panning 1
• Type: non-technical
• Proposed by: nikomatsakis
• Link: TBD, see summary below
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

Summary

We're going to need to form intelligent thoughts about the roadmap as a team. This meeting would review some of the goals we had from 2019 and kickstart discussion on what our goals might be over the next year.

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Based on current experience with working groups, we should begin to document some best practices with what has been working and what hasn't.

Meeting proposal info

• Title: merge llvm.sideeffect change
• Type: technical
• Proposed by: @nikomatsakis
• Link: (inline, see below)
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

Proposal details

Rust has had a long-standing problem where LLVM optimizes empty loops into UB. This can very easily create real bugs for folks. We've got a pending PR (#59546) that fixes this by inserting llvm.sideeffect instructions, but until recently it was blocked on getting some lolbench measurements done. These measurements were recently completed (thanks @mati865!). They suggest the impact is "generally" small but non-zero (I put them in a world readable spreadsheet here, feel free to copy and play with it). We need to make a decision whether this is good enough! I'm going to cc the @rust-lang/lang team since I think lang team input would be useful here.

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Meeting proposal info

• Title: incremental dep-graph storage
• Type: technical
• Proposed by: @nikomatsakis, @Zoxc, @michaelwoerister
• Link: hackmd doc
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

Summary

In our meeting today, we decided to try and cover #60035 in more detail in a follow-up meeting. @nikomatsakis is going to try to loop up with @Zoxc and @michaelwoerister to fill out the hackmd doc above with details on the proposal as well as questions and concerns to highlight.

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Can we make the "section headers" on the webpage clickable? e.g., like "meeting calendar" and the like. It seems that the anchors like #meeting-calendar exist -- they're just not easy to spot.

Some of them, for example "mw", are indecipherable unless you already know that it's an IRC (?) token that refers to @michaelwoerister.

Another that I noticed is "acrichto", perhaps there are some more.

It is desirable to have a schedule for working group check-ins so that this can be planned for and delegated, and to ensure that each working group is heard from regularly and succeeds in their goal. However, the current schedule requires regular manual updating and changes when new groups are added, we should devise a new system that requires less manual work to maintain.

Based on discussion on Zulip, work out what else needs changed with the initial version of the experts map and move it into this repository.

Meeting proposal info

• Title: Migrate rustc_interface queries
• Type: technical
• Proposed by: pnkfelix, Zoxc
• Link: internals post
  • (aka PRs rust-lang/rust#59064, rust-lang/rust#59205, rust-lang/rust#59282, rust-lang/rust#59338, rust-lang/rust#59404, rust-lang/rust#59904)
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

In #136 some content from the experts map was removed. :(

Meeting proposal info

After rust-lang/rust#64566, which was a prerequisite for dataflow-based const validation, there are two different frameworks for dataflow analysis in the compiler. I've written a prototype along with a design document for unifying the two frameworks.

The dataflow framework is an internal API (with the exception of one use in cargo-clippy), so this is a good time to improve it if desired. Accordingly, I've made some changes in the prototype, like passing Statements and Terminators directly into the effect methods, and making the signature of call_return_effect more similar to the others. If anyone has had difficulties implementing or inspecting the results of a dataflow analysis, it would be awesome to get your feedback here.

• Title: A unified framework for dataflow analysis
• Type: technical
• Proposed by: @ecstatic-morse
• Link: https://hackmd.io/@39Qr_z9cQhasi25sGjmFnA/Skvd9rztS
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

It seems like forge.rust-lang.org is becoming the home for policy documentation and the like. Let's migrate some of the stuff from the compiler-team repository over there.

Meeting proposal info

• Title: ICE-breaker groups
• Type: non technical
• Proposed by: @nikomatsakis
• Link: hackmd
• Scheduled dates for discussion: Sep 20, 2019

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

It'd be useful to highlight ICE-breakers, bisecters, and other sorts of bugs using a twitter account, ideally automatically. @pnkfelix mentioned the idea of retweeting when things go unassigned.

This is a (small) extension for future consideration, where we allow contributors/members to set a "subtitle" giving more details about their role in the team (e.g., designer, documentation wizard, coder, etc).

After this #103 was merged some minutes ended being missed, probably in the PR created and merged time window.

I guess that if we add back notes added in PRs in between PR #103 (website) and PR #120 (a PR after website was merged) and add back those meeting notes we would be golden.
Still a sanity check in general won't be a bad thing to do.

/cc @unbalancedparentheses @catalinasy

Meeting proposal info

• Title: Maintenance and triage
• Type: non-technical
• Proposed by: @nikomatsakis
• Link: https://hackmd.io/dvgegmdgQVSMbC4rcjG6EA?view
• Scheduled dates for discussion:
  • 2019-05-31 -- pending creating more of a plan (no such plan was created)
  • 2019-06-28

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Extend existing out-of-tree crates policy to have more concrete steps for creating out-of-tree crates. @michaelwoerister has produced a document describing the steps they took setting up the measureme crate, incorporate ideas from this.

Meeting proposal info

• Title: Planning the 'gcx, 'tcx transition
• Type: technical
• Proposed by: @nikomatsakis (but cc @eddyb, @Zoxc)
• Link: hackmd document here
• Scheduled dates for discussion:
  • 2019-06-14

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Meeting proposal info

• Title: Shipping parallel rustc
• Type: both technical and non-technical
• Proposed by: nikomatsakis
• Link: https://hackmd.io/guktT0I4QG2GpIhaDo-0YA?view
• Scheduled dates for discussion:
  • May 17, 2019 -- to make a "go/no-go" decision, pre-req is to gather data

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

The current repository is just a bunch of mark down files in a directory. This is very hip and low-tech, but it'd be nice if we could have automatically rendered content. A partial list follows:

• the working group table on the front page
• the working group check-in
• a blog and an announcement page
• the expert map could be rendered from a machine-readable TOML file

If we ported over to a jekyll setup and publishing via github pages, that would be awesome.

Meeting proposal info

• Title: Creating a OSS Fuzz project for Rust Compiler and stdlib
• Type: Technical, but it's complicated, depends involvement. The gist explains it well.
• Proposed by: https://github.com/SiavoshZarrasvand/
• Link: https://gist.github.com/SiavoshZarrasvand/309028bc3fe42ee6af46be84a930e93d
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

We need to turn rust-lang/rfcs#2689 into reality.

Meeting proposal info

• Title: rustc-ide
• Type: technical
• Proposed by: @matklad
• Link: https://gist.github.com/matklad/2d5f89a394cc70da97e5282fd6d88ef2
• Scheduled dates for discussion: Sep 13, 2019

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

I thought I had setup my own fork already. The relevant commit is 6589685

You can comment on the commit directly and I'll open a PR with the requested changes.

@rust-lang/infra can we have bors + a locked master branch here, too?

I think all the links on the index of the website are giving 404. Giving a quick look at that I think those are missing a docs/ prefix.

Start here https://rust-lang.github.io/compiler-team/ and check Zulip link and the links in the table but I think all the relative links are broken.

Anyway a sanity check in general to the site would be good.

/cc @unbalancedparentheses @catalinasy

We should have a contributing section on https://rust-lang.github.io/compiler-team/.

It could say:

• sign up for zulip
• check out the rustc-guide
• look for easy, mentor issues
• join an ICE-breaker group
• follow along with a working group
• could also mention #t-compiler/help-wanted once it exists

Do we have content like this on rustc-guide?, maybe we should just have a contributing section that redirects there?.

rustc-guide should be the canonical home for that sort of thing, as it can go into a lot more depth, and we have a lot of that content.

Initial post will be looking for someone to do #73

This issue originally only aimed to unify the labels across compiler team crates, but was generalized to list all of the things listed in the out-of-tree crates policy. The original description is below.

In order to perform triage in the weekly meeting across nominated issues in all compiler-team maintained repositories, we should make sure that there are a consistent set of labels that are used and that we update the triage meeting agenda to point to these searches.

We had the meeting from #82 but we never created any kind of minutes!

Meeting proposal info

• Title: Who debugs the debuginfo
• Type: it's complicated
• Proposed by: pnkfelix
• Link: https://gist.github.com/pnkfelix/a9f86000840701d8474daadcef43e0e0
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

Quoting @nikomatsakis from Zulip:

So I was talking to the person who runs readrust.net on discord. I feel like we need better visibility for the summaries and activities of the various compiler working groups. I was envisioning that it would be nice to have a central blog that just contains these sorts of updates and announcements -- basically, the activity of each of the working groups. In fact, I suspect that the blog should be project wide, with the ability to filter by team, by working group, or by other things.

The readrust.net author encouraged me to write-up an issue with more details. Before doing that, I thought I would open up some discussion here.

I've also been wondering about the structure of the weekly meetings -- I was thinking that maybe, instead of pulling from the groups, each group should push updates, content, and questions, and we can review them in the triage meeting.

Originally, I had in mind that we would go round robin because I thought it'd be useful to be able to see if working groups haven't been active with updates in a while. But we can do that separately just by having the updates organized by working group and checking for working groups that haven't posted any comments in a while (or, honestly, just monitoring Zulip). This could be a signal to go check-in and see how things are going and if we can do anything to help.

The link from the issue template to the proposal template seems broken; it links to _proposal.md, but the template now appears in _index.md.