# Technical Documentation: rust-lang/compiler-team > ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/rust-lang/compiler-team) ### Overview (`README.md`) **UPDATE 2025-04-01** The website has been retired. All content is now available on: https://forge.rust-lang.org/compiler/index.html # Compiler Team This repository contains a static site that details the procedures, policies, working groups, planning documents and minutes. You are probably looking [for the rendered website](https://rust-lang.github.io/compiler-team/) instead. ### Building the website You'll need to install [Hugo](https://github.com/gohugoio/hugo#choose-how-to-install) (ensure to get Hugo extended version for SCSS support) to build the website locally, you can then run the following commands to set the website up: ``` git clone git@github.com:rust-lang/compiler-team.git git submodule update --init hugo server --minify ``` To generate a version for distribution, run `hugo --minify` and use the `public` directory. --- ### Overview (`templates/README.md`) This directory contains templates for various issues, meeting proposals, or other such things. --- ### Index (`content/_index.md`) --- title: Introduction type: docs --- # compiler-team A home for compiler team planning documents, meeting minutes, and other such things. If you're interested in learning about how **rustc** works -- as well as advice on building the compiler, preparing a PR, and other similar topics -- check out the [rustc-dev-guide]. [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ ## Quick facts - **Where to find us:** We are primarily present on [Zulip](about/chat-platform), though some of us also monitor Discord. - **Want to attend a meeting or follow along?** See the "meeting calendar" section below. - **Looking for technical information about how the compiler works?** Check out the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/). ## Meeting Calendar Our meeting calendar is publicly available from the following links: - [Web Link][embed] -- use this to view the calendar or to import into Google Calendar - [ICS file, for use outside from google calendar][ics] -- use this if you want to import into different calendar software Unless otherwise noted, all our meetings are open to the public and held on Zulip, in the [t-compiler/meetings stream](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings). There are two main team-wide meetings that we hold on a regular basis. There are also a variety of working group meetings. ### Triage meeting We have a [weekly triage meeting][triage] to discuss and track regressions and urgent changes. This meeting is held on Zulip and open to anyone. ### Steering meeting We also have a [regular steering meeting][steering] where we discuss proposed designs, changes to our process, and other topics. The topics are scheduled at a planning meeting that occurs every four weeks. - **Have an idea?** Click here to propose a topic to be scheduled by [filing an issue][propose] with the correct template. - **To see the current scheduled meetings**, check out the [meeting calendar](#meeting-calendar). [triage]: about/triage-meeting [steering]: about/steering-meeting [embed]: https://calendar.google.com/calendar/embed?src=mfbugia4q2487tj9h08aimhd8e38dc8k%40import.calendar.google.com [ics]: https://rust-lang.github.io/calendar/compiler.ics [propose]: https://github.com/rust-lang/compiler-team/issues/new/choose ## Working Groups Much of the ongoing work and initiatives from the compiler team are performed by working groups. Working groups are a great way for new contributors to get involved as they provide a stream of tasks all focused around one area and have designated channels for help and advice. All of the active working groups are listed below: Name | Status | Short Description | Zulip Stream ---- | ------ | ----------------- | ------------ [Async-await Implementation](working-groups/async-await/) | Active | Implementing async-await | [#t-compiler/wg-async-await][async-await_stream] [Diagnostics](working-groups/diagnostics/) | Active | Use crates.io crates for diagnostics rendering and make emitting diagnostics nicer. | [#t-compiler/wg-diagnostics][diagnostics_stream] [Rustc Dev Guide](working-groups/rustc-dev-guide/) | Active | Make the compiler easier to learn by ensuring that rustc-dev-guide is "complete" | [#t-compiler/wg-rustc-dev-guide][rustc-dev-guide_stream] [LLVM](working-groups/llvm/) | Incubating | Working with LLVM upstream to represent Rust in its development | [#t-compiler/wg-llvm][llvm_stream] [Meta](working-groups/meta/) | Paused | How compiler team organizes itself | [#t-compiler/wg-meta][meta_stream] [MIR Optimizations](working-groups/mir-opt/) | Active | Write MIR optimizations and refactor the MIR to be more optimizable. | [#t-compiler/wg-mir-opt][mir-opt-stream] [Non-Lexical Lifetimes (NLL)](working-groups/nll/) | Retired | Implementing non-lexical lifetimes | [#t-compiler/wg-nll][nll_stream] [Parallel-rustc](working-groups/parallel-rustc/) | Paused | Making parallel compilation the default for rustc | [#t-compiler/wg-parallel-rustc][parallel-rustc_stream] [Polonius](working-groups/polonius/) | Active | Exploring the integration of the "NLL 2.0"-like ["Polonius analysis"][Polonius] into rustc | [#t-compiler/wg-polonius][polonius_stream] [Polymorphization](working-groups/polymorphization/) | Active | Implement an analysis to detect when functions can remain polymorphic during code generation. | [#t-compiler/wg-polymorphization][polymorphization_stream] [Prioritization](working-groups/prioritization/) | Active | Triaging bugs, mainly deciding if bugs are critical (potential release blockers) or not. | [#t-compiler/wg-prioritization][prioritization_stream] [Profile-Guided Optimization](working-groups/pgo/) | Retired | Implementing profile-guided optimization for rustc | [#t-compiler/wg-profile-guided-optimization][pgo_stream] [RFC 2229](working-groups/rfc-2229/) | Retired | Make a closure capture individual fields of the variable rather than the entire composite variable | [#t-compiler/wg-rfc-2229][rfc-2229-stream] [RLS 2.0](working-groups/rls-2.0/) | Active | Experimenting with a new compiler architecture tailored for IDEs | [#t-compiler/wg-rls2.0][rls20_stream] [Rustc pipelining](working-groups/pipelining/) | Retired | Enable Cargo to invoke rustc in a pipelined fashion, speeding up crate graph compiles. | [#t-compiler/wg-pipelining][pipelining-stream] [Self-Profile](working-groups/self-profile/) | Active | Improving the `-Z self-profile` feature | [#t-compiler/wg-self-profile][self-profile_stream] [Traits](working-groups/traits/) | Active | Improving the trait-system design + implementation | [#t-compiler/wg-traits][traits_stream] [Weekly, in Zulip]: #meeting-calendar [nll_stream]: https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll [llvm_stream]: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm [meta_stream]: https://rust-lang.zulipchat.com/#narrow/stream/185694-t-compiler.2Fwg-meta [rls20_stream]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0 [traits_stream]: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-compiler.2Fwg-traits [async-await_stream]: https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await [self-profile_stream]: https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile [pgo_stream]: https://rust-lang.zulipchat.com/#narrow/stream/187830-t-compiler.2Fwg-profile-guided-optimization [parallel-rustc_stream]: https://rust-lang.zulipchat.com/#narrow/stream/187679-t-compiler.2Fwg-parallel-rustc [rfc-2229-stream]: https://rust-lang.zulipchat.com/#narrow/stream/189812-t-compiler.2Fwg-rfc-2229 [mir-opt-stream]: https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt [pipelining-stream]: https://rust-lang.zulipchat.com/#narrow/stream/195180-t-compiler.2Fwg-pipelining [polonius_stream]: https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius [polymorphization_stream]: https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization [rustc-dev-guide_stream]: https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide [Polonius]: https://github.com/rust-lang/polonius [diagnostics_stream]: https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics [prioritization_stream]: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization ## Procedures The [procedures directory](procedures) contains descriptions of various rustc procedures. ## Code of Conduct and licensing All interactions on this repository (whether on issues, PRs, or elsewhere) are governed by the [Rust Code of Conduct](about/code_of_conduct/). Further, all content on this repository is subject to the standard [Rust](https://github.com/rust-lang/compiler-team/blob/master/LICENSE-MIT) [licensing](https://github.com/rust-lang/compiler-team/blob/master/LICENSE-APACHE). --- ### About Index (`content/about/_index.md`) --- title: Compiler team type: docs --- # About Compiler Team # --- ### Menu Index (`content/menu/index.md`) --- headless: true --- - **About** - [Code of Conduct]({{< relref "/about/CODE_OF_CONDUCT" >}}) - [Chat Platform]({{< relref "/about/chat-platform" >}}) - [Steering Meeting]({{< relref "/about/steering-meeting" >}}) - [Triage Meeting]({{< relref "/about/triage-meeting" >}}) - **Minutes** - [Design Meetings]({{< relref "/minutes/design-meeting" >}}) - [Steering Meetings]({{< relref "/minutes/steering-meeting" >}}) - [Triage Meetings]({{< relref "/minutes/triage-meeting" >}}) - **Procedures** - [Documentation]({{< relref "/procedures" >}}) - [Crates]({{< relref "/procedures/crates" >}}) - [Call for participation]({{< relref "/procedures/call-for-participation" >}}) - [Form new working group]({{< relref "/procedures/form-new-working-group" >}}) - [**Working Groups**]({{< relref "/working-groups" >}}) - [Async Await]({{< relref "/working-groups/async-await" >}}) - [Debugging]({{< relref "/working-groups/debugging" >}}) - [Diagnostics]({{< relref "/working-groups/diagnostics" >}}) - [Rustc Dev Guide]({{< relref "/working-groups/rustc-dev-guide" >}}) - [LLVM]({{< relref "/working-groups/llvm" >}}) - [Meta]({{< relref "/working-groups/meta" >}}) - [MIR-opt]({{< relref "/working-groups/mir-opt" >}}) - [NLL]({{< relref "/working-groups/nll" >}}) - [parallel rustc]({{< relref "/working-groups/parallel-rustc" >}}) - [PGO]({{< relref "/working-groups/pgo" >}}) - [pipelining]({{< relref "/working-groups/pipelining" >}}) - [polonius]({{< relref "/working-groups/polonius" >}}) - [polymorphization]({{< relref "/working-groups/polymorphization" >}}) - [Prioritization]({{< relref "/working-groups/prioritization" >}}) - [rfc-2229]({{< relref "/working-groups/rfc-2229" >}}) - [rls-2.0]({{< relref "/working-groups/rls-2.0" >}}) - [Self Profile]({{< relref "/working-groups/self-profile" >}}) - [Traits]({{< relref "/working-groups/traits" >}}) --- ### Procedures Index (`content/procedures/_index.md`) --- title: Procedures type: docs --- # Procedures of the Compiler Team # Compiler team procedures are documented on the [Rust forge](https://forge.rust-lang.org/compiler/index.html). --- ### Working Groups Index (`content/working-groups/_index.md`) --- title: Working Groups type: docs --- # Working Groups This directory contains the notes for each of the active working groups. Each folder contains a few files, along with files specific to that working group: - `README.md` -- describes the basic details of the working group and how to get involved - `NOTES.md` -- updated regularly with the latest news - `FAQ.md` -- a place to document the answer to frequently asked questions An exhaustive list of working groups can be found [at the root of this repository](../). ## Guidelines These guidelines exist to serve team members who are about to start a new working group. ### Mentoring Issues [Mentored issues] are a great way for new contributors to get involved without needing to ask for a good first issue and wait for a response. When creating mentored issues, open a topic in the Zulip stream and link to it from the mentoring instructions for people to leave a message in if they are interested. [Mentored issues]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-mentor+no%3Aassignee ### Compiler Team Check-in Each week, a rotating set of working groups will check-in with the compiler team at the end of the compiler team's weekly triage meeting. By default, the working group's leads will handle this however a designated liaison can be sent instead - as long as whomever is running the meeting is informed. Consider scheduling any meetings before the compiler team check-in and encourage each contributor to add status updates to a shared document. This can make it easier to write notes for this repository and to check-in. ### Meetings The working group itself is not required to hold meetings, however should the group feel it would be helpful then they are free to. Any meetings should be added to the compiler team calendar so that other interested parties can find out about the meeting. If meetings are not held, then it would still be desirable to keep the `NOTES.md` in the working group's directory up-to-date. ### Membership Typically working groups don't have formal members outside of the specified leads. Those interested in participating in a working group can instead subscribe to the working group in order to be added to relevant groups for notification purposes. #### Explanation Membership would be useful for recognizing regular participants of a working group and providing a team lead with a group of people distribute work amongst. However, as it is desirable to enable anyone to easily add themself as a member of a working group they are interested in participating in - so they can receive notifications and assigned tasks - this has the effect of limiting the extent to which working group membership can be used to recognize regular participants. Therefore, formal membership is typically not pursued. --- ### Minutes Design Meeting Index (`content/minutes/design-meeting/_index.md`) --- title: Design meeting type: docs --- # Design Meetings {{< list-files "content/minutes/design-meeting" >}} --- ### Minutes Steering Meeting Index (`content/minutes/steering-meeting/_index.md`) --- title: Steering Meeting type: docs --- # Steering Meetings {{< list-files "content/minutes/steering-meeting" >}} --- ### Minutes Triage Meeting Index (`content/minutes/triage-meeting/_index.md`) --- title: Triage meeting type: docs --- # Triage Meetings {{< list-files "content/minutes/triage-meeting" >}} --- ### Working Groups Async Await Index (`content/working-groups/async-await/_index.md`) --- title: Async Foundations working group type: docs --- # Async Foundations Working Group ![working group status: active][status] This working group is focused around implementation/design of the "foundations" for Async I/O. This includes the `async-await` language feature but also the core `Future` trait and adapters. - **Team:** [wg-async-foundations on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-async-foundations.toml). - **Zulip stream:** [#wg-async-foundations][zulip] on Zulip **See the [wg-async-foundations repo][repo] for more information and how to get involved.** [repo]: https://github.com/rust-lang/wg-async-foundations [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations [nikomatsakis]: https://github.com/nikomatsakis [tmandry]: https://github.com/tmandry [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge --- ### Working Groups Debugging Index (`content/working-groups/debugging/_index.md`) --- title: Debugging Working Group type: docs --- # Debugging Working Group ![working group status: active][status] This working group's focus is to provide users with a good experience when debugging Rust code. - **Team:** [wg-debugging on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-debugging.toml) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Improve the debuginfo generated by rustc so that it is accurate and useful to debuggers - Support efforts to split debuginfo from binary artifacts - Better integrate with trace-based debuggers - Triage the backlog of `A-debuginfo` issues - Increase the size of the debuginfo test suite and ensure we have good test coverage ## How can I get involved? If you are interested in getting involved in this working group, you should stop by the Zulip stream and introduce yourself! - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-debugging`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com ## What if I don't have much time? Consider re-testing issues in the `rust` repository and leaving a comment to confirm if it is still an issue or not. Resolved issues should also have regression tests added. ## Are there any resources so I can get up to speed? The rustc-dev-guide has a chapter on [debugging support in the Rust compiler](https://rustc-dev-guide.rust-lang.org/debugging-support-in-rustc.html). ## Do I need to attend any meetings? We don't have regularly scheduled meetings yet. --- ### Working Groups Diagnostics Index (`content/working-groups/diagnostics/_index.md`) --- title: Diagnostics Working Group type: docs --- # Diagnostics Working Group ![working group status: active][status] This working group aims to make rustc better at telling the user why the compiler isn’t smart enough to understand their code yet. - **Team:** [wg-diagnostics on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-diagnostics.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/diagnostics/NOTES" >}}) - **Meeting Driver Plan:** [On Hackmd](https://hackmd.io/T9yQwLQ0SIOguR1auo3SHQ) - **FAQ:** [All]({{< relref "/working-groups/diagnostics/FAQ" >}}) [oli-obk]: https://github.com/oli-obk [estebank]: https://github.com/estebank [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Make diagnostics emitting independent of the happy code path - Separate the diagnostics rendering from the compiler so it can be reused by others. # How can I get involved? If you are interested in getting involved in this working group, you should introduce yourself in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] - https://github.com/rust-lang/rust/tree/master/src/librustc_errors - https://github.com/rust-lang/rust/blob/master/src/librustc_errors/json.rs - https://github.com/rust-lang/rust/tree/master/src/librustc_lint - https://crates.io/crates/annotate-snippets - https://crates.io/crates/codemap-diagnostic - **Zulip stream:** [`#t-compiler/diagnostics`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics ## What if I don't have much time? If you don't have time to contribute code, consider setting up meetings and frequently pinging working group members on related issues to discuss or fix them. ## Are there any resources so I can get up to speed? Not yet. ## Do I need to attend any meetings? We don't have any meetings yet. --- ### Working Groups Llvm Index (`content/working-groups/llvm/_index.md`) --- title: LLVM working group type: docs --- # LLVM Working Group ![working group status: incubating][status] [status]: https://img.shields.io/badge/status-incubating-yellow.svg?style=for-the-badge This working group encompasses work in LLVM upstream fixing the issues and implementing features that matter to Rust: - **Team:** [wg-llvm on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-llvm.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/llvm/NOTES" >}}) - **FAQ:**[All]({{< relref "/working-groups/llvm/FAQ" >}}) [nagisa]: https://github.com/nagisa # How can I get involved? If you are interested in getting involved in this working group, you should introduce yourself or send a message in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo], [`rust-lang/llvm-project`][llvm-downstream] - **Zulip stream:** [`#t-compiler/wg-llvm`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [llvm-downstream]: https://github.com/rust-lang/llvm-project [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm ## Are there any resources so I can get up to speed? ### LLVM Specific Documentation: - You can find documentation on LLVM at the [LLVM documentation index]. Some cherry picked resources are listed below: - [Getting Started with the LLVM System] describes how to configure and build LLVM from source. - The [Intro to LLVM] chapter of "The Architecture of Open Source Applications" provides a great introduction to LLVM. - The [LLVM Language Reference] describes the LLVM intermediate representation in great detail, but remains quite readable. - Before submitting your first patch upstream to LLVM, consider reading [Contributing to LLVM] and [LLVM GitHub User Guide]. ### Rust Specific Documentation: - You might want to read the [codegen section] of the [rustc-dev-guide] for more information on codegen and debugging LLVM in `rustc`. ## Do I need to attend any meetings? Currently the working group is incubating, pending more time available from the people spearheading the effort, and no meetings are being held in the meantime. ## How to find things to do? [A-LLVM][a-llvm] label in the `rust-lang/rust` repository categorises the issues which have something to do with how LLVM works. For the time being this is the best place to start. [a-llvm]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-LLVM [LLVM documentation index]: https://llvm.org/docs/ [LLVM Language Reference]: https://llvm.org/docs/LangRef.html [Contributing to LLVM]: https://www.llvm.org/docs/Contributing.html [LLVM GitHub User Guide]: https://llvm.org/docs/GitHub.html [Getting Started with the LLVM System]: https://www.llvm.org/docs/GettingStarted.html [Intro to LLVM]: http://www.aosabook.org/en/llvm.html [codegen section]: https://rustc-dev-guide.rust-lang.org/backend/codegen.html [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ --- ### Working Groups Meta Index (`content/working-groups/meta/_index.md`) --- title: Meta Working Group type: docs --- # Meta Working Group ![working group status: paused][status] This working group is dedicated to fleshing out the details of how the compiler team will organize itself. - **Team:** [wg-meta on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-meta.toml) - **[Planning document][planning]** - **Meeting Notes:**[All]({{< relref "/working-groups/meta/NOTES" >}}) - **FAQ:** [All]({{< relref "/working-groups/meta/FAQ" >}}) - **RFC - drafts:** [RFC - drafts] ({{< relref "/working-groups/meta/rfc-drafts" >}}) [status]: https://img.shields.io/badge/status-paused-yellow.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to discuss and answer the following unresolved questions: - How to organize compiler team calendar? - One calendar for everything or one per working group? - How to organize videos so people can find them? - e.g. playlists on YouTube, rustc-dev-guide chapter - How do we make it easy to add them? - Some are specific to a working group or limited subset of contributors? - How to run open-ended tasks? - e.g. lecture series, triage, rustc “university” - What is the role of the steering meeting? - In-depth discussion of topics that come up during the week? - Judge newer proposals? - Decide if the set of working groups should change? - When should we post agendas? - How should we get “inbound” prioritization requests? - e.g. if embedded working group has something they want or someone has a cool idea (pipelined compilation) - Use the steering meeting? - Expert list - Where should this be found? - This is related to “Advertising” the compiler team point below. - How should it be maintained? - What qualifies as expert? - Journeypeople - What should the name of this group be? - Criteria for membership? - Equivalent to r+ rights? - “Expiration” after some time? - How to make this a useful concept? - Relevant Q: what problem does this aim to solve? - Other clarifications: - Are journeypeople members of the compiler team or is this a step toward being a member of the team? - What is the expected conduct of a journeyperson? Does this change at all? Are there more expectations? - How can journeypeople be useful to existing full compiler team members? - Managing the mundane (ensuring everyone is added everywhere) - Interaction with `rust-lang/team` repository/effort by pietroalbini. - Need to work out what all the things people need access to are. - Working groups - What guidelines should exist for working groups? - e.g. effective meetings, note taking, check-ins at steering meetings, etc. - Directory structure in `rust-lang/compiler-team` repository - `index.md` and some other files already exist - Do we want more than this? - Assessing progress - Can we encourage working groups to set goals as part of their regular triage? - Goal: Leave check-in meeting feeling energized with clear ideas of next steps. - Design documents - How can we encourage up-front design and documentation? - How much is too much? - e.g. pipelined compilation, parallel rustc - How does this interact with the rustc-dev-guide? - API documentation - Should there be a working group focusing on this? - Async vs sync communication - Which is really easier? - Harder to make decisions over async. - Async can be easier for for non-native speakers. - Hard to keep up if too many commitments. - Sync can help throttle the volume. - Encourgages congeniality and cooperation. - Time zones are hard. - “Advertising” the compiler team - How to publicize the working groups and ways to contribute to the compiler team’s work? - e.g. landing page (website or `rust-lang/compiler-team` repo) - What information is useful for people looking to contribute? - When meetings are held, what is the purpose of each meeting, who should attend, where are the meetings held? - Who is the best person to contact about specific areas in the compiler? What is the best way to contact them? - What working groups are available? What is working group X doing? Where can I find a working group? Who is in a working group? Are there meetings? Do I need to attend? Do I need any prior experience? Are there resources that would help me get up to speed? Are there labels on the issues for this working group? Who is leading the working group? - What working groups might start in future? How can I register my interest in them? - What are best practices for contributing? (inspired by: youtu.be/voXVTjwnn-U?t=1862) - Documenting compiler team practices and policies - What is and isn’t the team responsible for? - What are the policies are regarding third party crates, crate maintainership, etc.? - What are the compiler team’s roadmap and goals for the year? - Triage tasks - Processes for future compatibility warnings # How can I get involved? If you are interested in getting involved in this working group, you should try attend a meeting and introduce yourself or send a message in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/compiler-team`][repo] - **Zulip stream:** [`#t-compiler/wg-meta`][zulip] on Zulip [planning]: https://paper.dropbox.com/doc/meta-working-group-planning--AZIyyFu~OaIwneVQkZ_6_T3vAg-09U5endyK7vaoQhaiQ7TI [repo]: https://github.com/rust-lang/compiler-team [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/185694-t-compiler.2Fwg-meta [nikomatsakis]: https://github.com/nikomatsakis [davidtwco]: https://github.com/davidtwco [spastorino]: https://github.com/spastorino --- ### Working Groups Mir Opt Index (`content/working-groups/mir-opt/_index.md`) --- title: MIR Optimizations (mir-opt) Working Group type: docs --- # MIR Optimizations (mir-opt) Working Group ![working group status: active][status] This working group aims to implement MIR optimizations and do the groundwork necessary to enable writing MIR optimizations. - **Team:** [wg-mir-opt on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-mir-opt.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/mir-opt/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/mir-opt/FAQ" >}}) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge [oli-obk]: https://github.com/oli-obk ## What is the goal of this working group? This working group aims to accomplish the following: - Implement new MIR optimizations - Refactor the MIR to be more optimizeable # How can I get involved? If you are interested in getting involved in this working group, you should introduce yourself in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] (specifically `src/librustc_mir/transform`) - **Zulip stream:** [`#t-compiler/mir-opt`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt ## What if I don't have much time? If you don't have time to contribute code, consider tagging issues in the `rust` repository so the team can find them. ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - MIR is an intermediate representation used within the compiler. We are looking to transform instances of MIR into "better" instances. You can read about the MIR in the [relevant rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/mir/index.html). ## Do I need to attend any meetings? We don't have any meetings yet. --- ### Working Groups Nll Index (`content/working-groups/nll/_index.md`) --- title: Non Lexical Lifetimes (NLL) Working Group type: docs --- # Non-Lexical Lifetimes (NLL) Working Group ![working group status: retired][status] This working group aims to implement non-lexical lifetimes (NLL), as described in RFC 2094: > Extend Rust's borrow system to support non-lexical lifetimes -- these are lifetimes that are > based on the control-flow graph, rather than lexical scopes. The RFC describes in detail how > to infer these new, more flexible regions, and also describes how to adjust our error messages. > The RFC also describes a few other extensions to the borrow checker, the total effect of which is > to eliminate many common cases where small, function-local code modifications would be required > to pass the borrow check. - **Team:** [wg-nll on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-nll.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/nll/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/nll/FAQ" >}}) [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge ## Status NLL has **landed** in the Rust 2018 edition and is currently in **migration** mode. The working group is currently working towards enabling NLL by default, for all editions, and in the full, non-migration mode. ## What is the goal of this working group? This working group aims to accomplish the following: - Implement a new borrow checker based on the MIR that supports non-lexical lifetimes. - Handle the migration from the existing AST-based borrow checker. # How can I get involved? If you are interested in getting involved in this working group, you should try to attend a meeting and introduce yourself or send a message in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] (specifically `src/librustc_mir/borrow_check`) - **Zulip stream:** [`#t-compiler/wg-nll`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll ## What if I don't have much time? If you don't have time to contribute code, consider using `#![feature(nll)]` to help find bugs with NLL. If you do, we'd love it if you could file an issue. ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - MIR is an intermediate representation used within the compiler. NLL is implemented as a new borrow checker implemented on the MIR. You can read about the MIR in the [relevant rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/mir/index.html). - You can read about the major phases and internals of the MIR borrow checker in it's [rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/borrow_check.html). - NLL was originally specified in [RFC 2094](https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md). - [@nikomatsakis][nikomatsakis]'s blog posts on NLL are also useful for getting familiar with the goals of NLL and some initial implementation ideas. * [Introduction][introduction], [NLL based on liveness][liveness] and [NLL adding the outlives relation][outlives]. [introduction]: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ [liveness]: http://smallcultfollowing.com/babysteps/blog/2016/05/04/non-lexical-lifetimes-based-on-liveness/ [outlives]: http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/ ## Do I need to attend any meetings? The NLL working group meets regularly for triage and discussion of high priority issues - see the [compiler team meeting calendar](../../../#meeting-calendar) for the most up to date time. Attendance is not mandatory but recommended as this can be a good opportunity to ask any questions and find new issues to work on. ## What do all these NLL labels mean? The NLL working group monitors the [**A-NLL**][A-NLL] label for issues relating to NLL. The follow extra labels are used during the working group's prioritization and triage, in roughly priority order: - [**NLL-sound**][NLL-sound] labels bugs around examples of code that is meant to be rejected by NLL. Usually such bugs are either ICE'ing or being erroneously accepted by NLL. *NLL-sound* things tend to be higher priority than *NLL-complete* things, at least at the moment. - [**NLL-performant**][NLL-performant] is for cases where NLL is causing *slow, slow, slow* compile times. - [**NLL-complete**][NLL-complete] labels bugs around examples of code that is meant to be accepted by NLL. Usually such bugs are either ICE'ing or being erroneously rejected by NLL. - [**NLL-reference**][NLL-reference] labels any issues relating to documenting NLL's behaviour into the language reference. - [**NLL-diagnostics**][NLL-diagnostics] labels cases where the diagnostics emitted by NLL specifcally needs improvement. Usually it is/was used for cases where NLL is a regresion w.r.t diagnostics when compared to AST-borrowck (but at this point its really more of a catch-all for any diagnostic issue originating from the NLL code base). Other NLL labels also exist: - [**NLL-fixed-by-NLL**][NLL-fixed-by-NLL] labels bugs that are problems solely with the AST-borrowck -- they are bugs that we intend to close once everyone migrates over to NLL. - [**NLL-polonius**][NLL-polonius] labels bugs related to the Polonius subproject - see the Polonius working group for more information on these. [A-NLL]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3AA-NLL [NLL-sound]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-sound [NLL-performant]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-performant [NLL-complete]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-complete [NLL-reference]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-reference [NLL-diagnostics]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-diagnostics [NLL-fixed-by-NLL]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-fixed-by-NLL [NLL-polonius]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-polonius [nikomatsakis]: https://github.com/nikomatsakis [pnkfelix]: https://github.com/pnkfelix --- ### Working Groups Parallel Rustc Index (`content/working-groups/parallel-rustc/_index.md`) --- title: Parallel-rustc Working Group type: docs --- # parallel-rustc Working Group ![working group status: paused][status] - **Team:** [wg-parallel-rustc on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-parallel-rustc.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/parallel-rustc/NOTES" >}}) - **Minutes:** - [2019.05.10]({{< relref "/working-groups/parallel-rustc/minutes/2019.05.10.md" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/parallel-rustc/FAQ" >}}) [Zoxc]: https://github.com/Zoxc [aturon]: https://github.com/aturon [status]: https://img.shields.io/badge/status-paused-yellow.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Finish, optimize, and test the implementation of parallel compilation to an extent that allows making it the default. - Produce solid documentation of how parallel evaluation works, how it is implementated, and what things it might affect in the [rustc-dev-guide][rustc-dev-guide]. [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ # How can I get involved? If you are interested in getting involved in this working group, you are welcome to introduce yourself in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-parallel-rustc`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/187679-t-compiler.2Fwg-parallel-rustc ## What if I don't have much time? If you don't have time to contribute code but you do compile your own compiler, the consider setting `parallel-compiler = true` in your `config.toml`. If you find a bug, we'd love it if you could file an issue. ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - Zoxc's [introductory post][zoxc-internals-post] in the _internals_ forum. - More to come... [zoxc-internals-post]: https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606 --- ### Working Groups Parselib Index (`content/working-groups/parselib/_index.md`) --- title: Parselib Working Group type: docs --- # Parselib Working Group ![working group status: active][status] The goal of the working group is to librarify rustc parser and share it between rustc and rust-analyzer. - **Team:** [wg-parselib on rust-lang/team][team] [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Core goal: rust-analyzer and rustc use the same code for parsing Rust -- a shared parser which is production ready (like rustc) and can build full-fidelity syntax trees for code with syntax errors (like rust-analyzer). - Stretch goal: produce a "nice enough" parser library which can be used even outside of rustc or rust-analyzer. - Non goal: produce a shared syntax tree representation. # How can I get involved? At the moment, there list of action items is pretty short -- we are still figuring out what to do, concretely. If you're interested in getting involved then feel free to pop into the Zulip stream. - **Desired experience level:** Familiarity with rustc and rust-analyzer parsers. - **Relevant repositories:** [`rust-lang/rust`][rust], [`rust-lang/wg-grammar`][wg-grammar], [`rust-analyzer/rust-analyzer`][rust-analyzer], [`rust-analyzer/ungrammar`][ungrammar]. - **Zulip stream:** [`#t-compiler/wg-parselib`][zulip] on Zulip [rust]: https://github.com/rust-lang/rust [wg-grammar]: https://github.com/rust-lang/wg-grammar [rust-analyzer]: https://github.com/rust-analyzer/rust-analyzer [ungrammar]: https://github.com/rust-analyzer/ungrammar [team]: https://github.com/rust-lang/team/blob/master/teams/wg-parselib.toml [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/254930-t-compiler.2Fwg-parselib --- ### Working Groups Pgo Index (`content/working-groups/pgo/_index.md`) --- title: Profile-Guided Optimization (PGO) Working Group type: docs --- # Profile-Guided Optimization (PGO) Working Group ![working group status: retired][status] This working group aims to implement profile-guided optimization (PGO) in the Rust compiler. - **Team:** [wg-pgo on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-pgo.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/pgo/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/pgo/FAQ" >}}) *THIS WORKING GROUP HAS REACHED ITS GOALS AND IS IN RETIRED STATE. [PGO IS AVAILABLE](https://doc.rust-lang.org/rustc/profile-guided-optimization.html) IN THE STABLE RUST COMPILER.* [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Implement and stabilize profile-guided optimization in `rustc` (https://github.com/rust-lang/rust/issues/59913) # How can I get involved? If you are interested in getting involved in this working group, send a message in the Zulip stream. - **Desired experience level:** LLVM + PGO expert `;)` - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-profile-guided-optimization`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/187830-t-compiler.2Fwg-profile-guided-optimization ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - Tracking issue: https://github.com/rust-lang/rust/issues/59913 - Clang's [documentation on PGO](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization). Contains lots of useful information on PGO in LLVM. - @emilio's [initial PR](https://github.com/rust-lang/rust/pull/48346) for adding experimental support for PGO. - A presentation on [Profile-based Indirect Call Promotion in LLVM](https://llvm.org/devmtg/2015-10/slides/Baev-IndirectCallPromotion.pdf), an optimization enabled by PGO ## Do I need to attend any meetings? No. [michaelwoerister]: https://github.com/michaelwoerister --- ### Working Groups Pipelining Index (`content/working-groups/pipelining/_index.md`) --- title: Pipelining Working Group type: docs --- # Pipelining Working Group ![working group status: retired][status] - **Leads:** [@alexcrichton][alexcrichton], [@nnethercote][nnethercote] - **Meeting Notes:** [All]({{< relref "/working-groups/pipelining/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/pipelining/FAQ" >}}) [nnethercote]: https://github.com/nnethercote [alexcrichton]: https://github.com/alexcrichton [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Enable Cargo to invoke rustc in a pipelined fashion. Specifically enabling Cargo to start compiling dependants of a crate as soon as metadata becomes available, rather than waiting until the entire compilation is done before proceeding. # How can I get involved? If you are interested in getting involved in this working group, you are welcome to introduce yourself in the Zulip stream. This working group is relatively small in scope, though, so we may not have work for everyone to take on! - **Desired experience level:** Experienced - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-pipelining`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/195180-t-compiler.2Fwg-pipelining ## What if I don't have much time? We're not quite at the point where we can test out support in rustc, but when that's ready we can fill in some instructions here! ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - [Initial Cargo issue](https://github.com/rust-lang/cargo/issues/6660) - [Tracking issue on rustc side of things](https://github.com/rust-lang/rust/issues/58465) - [Old cargo tracking issue](https://github.com/rust-lang/cargo/issues/4831) --- ### Working Groups Polonius Index (`content/working-groups/polonius/_index.md`) --- title: Polonius Working Group type: docs --- # Polonius Working Group ![working group status: active][status] This working group aims to explore the integration of the so-called ["Polonius analysis"][P] into rustc. Polonius is effectively an "NLL 2.0"-like project, that aims to achieve two goals: - improve upon the borrow checker algorithm so that it can accept more rust programs than it currently does; - move the core logic of the borrow checker into an independent crate whose behavior can be easily tested and specified. The base Polonius algorithm was first introduced in [this blogpost][intro]. The [Polonius crate][P] has evolved significantly since then in terms of its implementation details and efficiency, and one of the goals of the working group is to extend the scope of the crate to define the full borrow check analysis. - **Team:** [wg-polonius on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-polonius.toml) - **Meeting Notes:** - [2019.03.07 Meeting]({{< relref "/working-groups/polonius/minutes/2019.03.07-meeting.md" >}}) - [2019.04.23 Meeting]({{< relref "/working-groups/polonius/minutes/2019.04.23-meeting.md" >}}) - [2019.04.30 Meeting]({{< relref "/working-groups/polonius/minutes/2019.04.30-meeting.md" >}}) - [2019.05.07 Meeting]({{< relref "/working-groups/polonius/minutes/2019.05.07-meeting.md" >}}) - [2019.05.14 Meeting]({{< relref "/working-groups/polonius/minutes/2019.05.14-meeting.md" >}}) - [2019.05.28 Meeting]({{< relref "/working-groups/polonius/minutes/2019.05.28-meeting.md" >}}) - [2019.06.04 Meeting]({{< relref "/working-groups/polonius/minutes/2019.06.04-meeting.md" >}}) - [2019.06.11 Meeting]({{< relref "/working-groups/polonius/minutes/2019.06.11-meeting.md" >}}) - **Screencasts**: [YouTube Playlist](https://www.youtube.com/playlist?list=PL85XCvVPmGQitE2CBzf-gERSqeXo59NQG) - **FAQ:** [FAQ]({{< relref "/working-groups/polonius/FAQ" >}}) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge # How can I get involved? We are still working on defining our roadmap and carving out independent tasks. If you'd like to get involved, the best idea right now is to introduce yourself in our Zulip stream -- and perhaps consider attending on our triage meetings. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] (specifically `src/librustc_mir/borrow_check`), [`rust-lang/polonius`][P], and [`rust-lang/datafrog`][DF] - **Zulip stream:** [`#t-compiler/wg-polonius`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [DF]: https://github.com/rust-lang/datafrog [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius [P]: https://github.com/rust-lang/polonius [intro]: http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/ [regionbp]: http://smallcultfollowing.com/babysteps/blog/2019/01/17/polonius-and-region-errors/ [regionhr]: http://smallcultfollowing.com/babysteps/blog/2019/01/21/hereditary-harrop-region-constraints/ ## Are there any resources so I can get up to speed? nikomatsakis's blog posts offer the best written documentation at the moment: - [An alias-based formulation of the borrow checker][intro] - [Polonius and region errors][regionbp] - [Polonius and the case of the hereditary harrop predicate][regionhr] ## Do I need to attend any meetings? We have a weekly sync meeting. Check the [compiler team meeting calendar](../README.md#meeting-calendar) for the most up to date time. Attendance is not mandatory but recommended as this can be a good opportunity to ask any questions and find new issues to work on. [nikomatsakis]: https://github.com/nikomatsakis [lqd]: https://github.com/lqd --- ### Working Groups Polymorphization Index (`content/working-groups/polymorphization/_index.md`) --- title: Polymorphization Working Group type: docs --- # Polymorphization Working Group ![working group status: paused][status] [status]: https://img.shields.io/badge/status-paused-yellow.svg?style=for-the-badge This working group aims to implement an analysis to detect when functions could remain polymorphic during code generation. - **Team:** [wg-polymorphization on rust-lang/team][team] ## What is the goal of this working group? This working group aims to accomplish the following: - Initially, implement an analysis to detect when type parameters are unused in functions, closures and methods; and integrate this analysis into the monomorphization infrastructure so that less copies of functions are redundantly made (this addresses rust-lang/rust#46477). - Experiment and investigate extending the analysis to more advanced cases where functions could be kept polymorphic. For example, if a function only uses the size of a type parameter, rustc could create a copy for each distinct size of type (rather than each type). # How can I get involved? There isn't a massive amount of work to be done in parallel relating to polymorphization, but if you're interested in getting involved then feel free to pop into the Zulip stream. - **Desired experience level:** Some familiarity with the MIR and substitutions - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-polymorphization`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization [nikomatsakis]: https://github.com/nikomatsakis [davidtwco]: https://github.com/davidtwco [team]: https://github.com/rust-lang/team/blob/master/teams/wg-polymorphization.toml --- ### Working Groups Prioritization Index (`content/working-groups/prioritization/_index.md`) --- title: Prioritization Working Group type: docs --- # Prioritization Working Group ![working group status: active][status] Triaging bugs, mainly deciding if bugs are critical (potential release blockers) or not. - **Team:** [wg-prioritization on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-prioritization.toml) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge [spastorino]: https://github.com/spastorino [wesleywiser]: https://github.com/wesleywiser ## What is the goal of this working group? This working group aims to accomplish the following: - Processing 'nominations' and routing bugs to folks who can fix them - Identifying *critical* bugs and monitoring them to ensure they are making progress - Identifying the agenda for compiler team triage meetings - Critical issues that are not making progress - Beta/Stable nominations to be backported - Issues where bugs are nominated for needing wider discussion - Tracking deferred things and ensuring they are picked up again - Future compatibility warnings ## How do people bring things to the working group's attention? If the issue priority seems obvious, people can label it accordingly, example an obviously "critical" issue can be labelled as `P-critical`. But if unclear, use the `I-prioritize` label to bring it to the group's attention. ## How can I get involved? If you are interested in getting involved in this working group, come and say hi [in our Zulip stream][zulip]. Also check out the [Rust compiler calendar](https://rust-lang.github.io/compiler-team/#meeting-calendar). You can also be added to the Zulip group for the working group if you are interested in being pinged when there are things that you may want to be involved with. ## Process Our workflow is detailed on [Rust Forge](https://forge.rust-lang.org/compiler/prioritization/procedure.html). - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][rust-repo], [rust-lang/compiler-team-prioritization][rust-prio], [rust-lang/triagebot][rust-triagebot] - **Zulip stream:** [`#t-compiler/wg-prioritization`][zulip] on Zulip [rust-repo]: https://github.com/rust-lang/rust [rust-prio]: https://github.com/rust-lang/compiler-team-prioritization [rust-triagebot]: https://github.com/rust-lang/triagebot [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization --- ### Working Groups Rfc 2229 Index (`content/working-groups/rfc-2229/_index.md`) --- title: rfc-2229 Working Group type: docs --- # rfc-2229 Working Group ![working group status: retired][status] - **Team:** [wg-rfc-2229 on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-rfc-2229.toml) - **Meeting Notes:** - Check [meetings.md](https://github.com/rust-lang/project-rfc-2229/blob/master/meetings.md) for latest meetings notes and video recordings. - Old: [2019.03.05 Roadmap Plan]({{< relref "/working-groups/rfc-2229/minutes/2019.03.05-roadmap-plan.md" >}}) - **Project Repository:** https://github.com/rust-lang/project-rfc-2229 - **FAQ:** [FAQ]({{< relref "/working-groups/rfc-2229/FAQ" >}}) ## Status Check the [project board](https://github.com/rust-lang/project-rfc-2229/projects/1). ## What is the goal of this working group? This working group aims to accomplish the following: - Finish, optimize, and test the implementation of [RFC-2229]. RFC 2229 changes the way closure-capture works so that we no longer capture entire individual variables, instead capture the actual path to fields of the variable, that is used. This helps to eliminate borrow check errors. - Produce documentation of how the closures in Rust are implemented in the [rustc-dev-guide] along the way. Currently, the rustc-dev-guide does not have a section on closures. We would like to change it. # How can I get involved? If you are interested in getting involved in this working group, you are welcome to introduce yourself in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] - **Zulip stream:** [`#t-compiler/wg-rfc-2229`][zulip] on Zulip ## Are there any resources to get up to speed? There are a few videos recorded by [niko][Niko] that give an excellent overview of how rustc implements closures and a detailed code walk-through. The videos can be found [here][playlist]. ## Can I contribute in ways other than code ? Definitely, you can. If you would like to have a deep understanding of closures but don't intend to write any code, help us add a section to the [rustc-dev-guide]. One way to do that will be to watch these [videos][playlist] and to summarize the closure implementation details discussed there in a new closure section of the rustc-dev-guide. # Roadmap The project roadmap can be found [here][roadmap]. [Niko]: https://github.com/nikomatsakis [Blitzerr]: https://github.com/blitzerr [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/189812-t-compiler.2Fwg-rfc-2229 [RFC-2229]: https://github.com/rust-lang/rfcs/blob/master/text/2229-capture-disjoint-fields.md [NOTES]: minutes/ [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge [roadmap]: https://paper.dropbox.com/doc/RFC-2229-Roadmap--AYuUod8hbXrktRttb95fprjHAg-cJKrePDCZR54T5kVbuoQk [playlist]: https://www.youtube.com/playlist?list=PL85XCvVPmGQh__bxYIxaVifbIOajnrNcQ&disable_polymer=true --- ### Working Groups Rls 2.0 Index (`content/working-groups/rls-2.0/_index.md`) --- title: rls-2.0 Working Group type: docs --- # rls-2.0 Working Group ![working group status: retired][status] [status]: https://img.shields.io/badge/status-active-green.svg?style=for-the-badge - **Team:** [wg-rls-2 on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-rls-2.toml) - **Notes:** [All]({{< relref "/working-groups/rls-2.0/NOTES" >}}) - **FAQs:** [FAQ]({{< relref "/working-groups/rls-2.0/FAQ" >}}) # Scope and purpose Discover ideal architecture for IDE-compiler by starting a "from scratch" implementation. Especially, how to handle the two hardest things: * name resolution/macro expansion * trait resolution Quantify how hard would be to port existing rustc to the IDE architecture. ## Secondary Goals * provide better RLS experience by making a "better racer" * facilitate rustc librarification by discovering and prototyping separable libraries * facilitate specification of the language, by producing "more declarative" implementation ## Deliverables * a language server which provides compiler-based code completion for a subset of the Rust language. * "design knowledge": which approaches do and do not work in IDE contexts. * (optional) improvements to existing tooling, like replacing racer in RLS with something more powerful, or making rustfmt capable of dealing with incomplete code. # Current status An initial language-server is implemented in the [rust-analyzer]. [rust-analyzer]: https://github.com/rust-analyzer/rust-analyzer # How to participate ## Chat forum On [the rust-lang Zulip][z], in [the `#t-compiler/rust-analyzer` stream][s]. [z]: https://rust-lang.zulipchat.com/ [s]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer ## Meetings We don't have a regular meeting schedule yet, check [Zulip][s] to learn about the next one. However, we maintain [work list] -- a paper document that shows what everyone is working on right now. If you want to (this is not mandatory), add yourself to the list! [work list]: https://paper.dropbox.com/doc/RLS-2.0-work-list--AZ3BgHKKCtqszbsi3gi6sjchAQ-42vbnxzuKq2lKwW0mkn8Y ## rust-analyzer Currently the bulk of work is happening in the [rust-analyzer] repository. It has [E-mentor] issues and a [guide]. [E-mentor]: https://github.com/rust-analyzer/rust-analyzer/issues?q=is%3Aissue+is%3Aopen+label%3AE-mentor [guide]: https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/dev/guide.md ## Getting up to speed There's some documentation in rust-analyzer repository which should be useful. There's a YouTube [playlist] with videos which cover various subsystems of the analyzer. [playlist]: https://www.youtube.com/playlist?list=PL85XCvVPmGQho7MZkdW-wtPtuJcFpzycE --- ### Working Groups Rustc Dev Guide Index (`content/working-groups/rustc-dev-guide/_index.md`) --- title: Rustc Dev Guide Working Group type: docs --- # Rustc Dev Guide Working Group ![working group status: active][status] This working group aims to make the compiler easier to learn by ensuring that rustc-dev-guide and api docs are "complete". - **Team:** [wg-rustc-dev-guide on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-rustc-dev-guide.toml) - **Meeting Notes:** - [2019.05.14 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.05.14-meeting.md" >}}) - [2019.05.28 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.05.28-meeting.md" >}}) - [2019.06.11 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.06.11-meeting.md" >}}) - [2019.06.25 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.06.25-meeting.md" >}}) - [2019.07.09 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.07.09-meeting.md" >}}) - [2019.07.23 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.07.23-meeting.md" >}}) - [2019.08.06 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.08.06-meeting.md" >}}) - [2019.08.20 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.08.20-meeting.md" >}}) - [2019.09.17 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.09.17-meeting.md" >}}) - [2019.10.01 Meeting]({{< relref "/working-groups/rustc-dev-guide/minutes/2019.10.01-meeting.md" >}}) - **Agenda:** [Agenda]({{< relref "/working-groups/rustc-dev-guide/minutes/agenda" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/rustc-dev-guide/FAQ" >}}) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge [spastorino]: https://github.com/spastorino [markim]: https://github.com/mark-i-m ## What is the goal of this working group? This working group aims to accomplish the following: - Ensure that major components of rustc are covered in rustc-dev-guide - Ensure that API doc coverage is at least 90% # How can I get involved? If you are interested in getting involved in this working group, come and say hi in the Zulip stream. You can be added to the Zulip group for the working group if you are interested in being pinged when there are available tasks. ## Process We are trying to follow a "sprint-like" structure where on each "sprint" cycle we start with a planning and then work towards the goals defined on that plan. Our current plan is to work for 2 months on a couple of goals, with a few meetings to sync up during that period. We are working towards filling out missing parts of the rustc-dev-guide and building some chapters that help gain an overall understanding of what the compiler does to code to produce its output. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][rust-repo] and [`rust-lang/rustc-dev-guide`][rustc-dev-guide-repo] - **Zulip stream:** [`#t-compiler/wg-rustc-dev-guide`][zulip] on Zulip [rust-repo]: https://github.com/rust-lang/rust [rustc-dev-guide-repo]: https://github.com/rust-lang/rustc-dev-guide [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide --- ### Working Groups Self Profile Index (`content/working-groups/self-profile/_index.md`) --- title: Self-Profile Working Group type: docs --- # Self-Profile Working Group ![working group status: retired][status] [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge This working group aims to improve the `-Z self-profile` `rustc` option which can aid in profiling the compiler during compilation. - **Team:** [wg-self-profile on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-self-profile.toml) - **Meeting Notes:** [All]({{< relref "/working-groups/self-profile/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/self-profile/FAQ" >}}) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Improve the `-Z self-profile` option in `rustc` which dumps various events into a file. - Implement additional tools to explore, visualize and understand the data contained in the output file. ## What is the current status? The working group is working on creating a "minimum viable product" of the self-profiling feature. Progress is tracked in https://github.com/rust-lang/rust/issues/58967. ## How can I get involved? If you are interested in getting involved in this working group, you should try attend a meeting and introduce yourself or send a message in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] (specifically `src/librustc/util/profiling.rs`) - **Zulip stream:** [`#t-compiler/wg-self-profile`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile ## Do I need to attend any meetings? The Self-Profile WG doesn't currently have recurring, scheduled meetings. However, anyone is welcome to attend any WG meetings. [michaelwoerister]: https://github.com/michaelwoerister [wesleywiser]: https://github.com/wesleywiser --- ### Working Groups Template Index (`content/working-groups/template/_index.md`) --- title: Working Group - Template type: docs --- #### *

This page is an example template and not the actual NLL working group.

* #### *

Don't forget to add this new working group to the end of the table at the root of this repository!

* # Non-Lexical Lifetimes (NLL) Working Group ![working group status: active][status] This working group aims to implement non-lexical lifetimes (NLL), as described in RFC 2094: > Extend Rust's borrow system to support non-lexical lifetimes -- these are lifetimes that are > based on the control-flow graph, rather than lexical scopes. The RFC describes in detail how > to infer these new, more flexible regions, and also describes how to adjust our error messages. > The RFC also describes a few other extensions to the borrow checker, the total effect of which is > to eliminate many common cases where small, function-local code modifications would be required > to pass the borrow check. - **Leads:** [@nikomatsakis][nikomatsakis] and [@pnkfelix][pnkfelix] - **Meeting Notes:** [All]({{< relref "/working-groups/template/NOTES" >}}) - **FAQ:** [FAQ]({{< relref "/working-groups/template/FAQ" >}}) [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge ## What is the goal of this working group? This working group aims to accomplish the following: - Implement a new borrow checker based on the MIR that supports non-lexical lifetimes. - Handle the migration from the existing AST-based borrow checker. # How can I get involved? If you are interested in getting involved in this working group, you should try to attend a meeting and introduce yourself or send a message in the Zulip stream. You can be added to the GitHub and Zulip group for the working group if you are interested in being pinged when there are available tasks. - **Desired experience level:** Any - **Relevant repositories:** [`rust-lang/rust`][repo] (specifically `src/librustc_mir/borrow_check`) - **Zulip stream:** [`#t-compiler/wg-nll`][zulip] on Zulip [repo]: https://github.com/rust-lang/rust [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll ## What if I don't have much time? If you don't have time to contribute code, consider using `#![feature(nll)]` to help find bugs with NLL. If you do, we'd love it if you could file an issue. ## Are there any resources so I can get up to speed? There are some resources available for those interested in contributing to get some background and context: - MIR is an intermediate representation used within the compiler. NLL is implemented as a new borrow checker implemented on the MIR. You can read about the MIR in the [relevant rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/mir/index.html). - You can read about the major phases and internals of the MIR borrow checker in it's [rustc-dev-guide chapter](https://rustc-dev-guide.rust-lang.org/borrow_check.html). - NLL was originally specified in [RFC 2094](https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md). - [@nikomatsakis][nikomatsakis]'s blog posts on NLL are also useful for getting familiar with the goals of NLL and some initial implementation ideas. * [Introduction][introduction], [NLL based on liveness][liveness] and [NLL adding the outlives relation][outlives]. [introduction]: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ [liveness]: http://smallcultfollowing.com/babysteps/blog/2016/05/04/non-lexical-lifetimes-based-on-liveness/ [outlives]: http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/ ## Do I need to attend any meetings? The NLL working group meets regularly for triage and discussion of high priority issues - see the [compiler team meeting calendar](../README.md#meeting-calendar) for the most up to date time. Attendance is not mandatory but recommended as this can be a good opportunity to ask any questions and find new issues to work on. ## What do all these NLL labels mean? The NLL working group monitors the [**A-NLL**][A-NLL] label for issues relating to NLL. The follow extra labels are used during the working group's prioritization and triage, in roughly priority order: - [**NLL-sound**][NLL-sound] labels bugs around examples of code that is meant to be rejected by NLL. Usually such bugs are either ICE'ing or being erroneously accepted by NLL. *NLL-sound* things tend to be higher priority than *NLL-complete* things, at least at the moment. - [**NLL-performant**][NLL-performant] is for cases where NLL is causing *slow, slow, slow* compile times. - [**NLL-complete**][NLL-complete] labels bugs around examples of code that is meant to be accepted by NLL. Usually such bugs are either ICE'ing or being erroneously rejected by NLL. - [**NLL-reference**][NLL-reference] labels any issues relating to documenting NLL's behaviour into the language reference. - [**NLL-diagnostics**][NLL-diagnostics] labels cases where the diagnostics emitted by NLL specifcally needs improvement. Usually it is/was used for cases where NLL is a regresion w.r.t diagnostics when compared to AST-borrowck (but at this point its really more of a catch-all for any diagnostic issue originating from the NLL code base). Other NLL labels also exist: - [**NLL-fixed-by-NLL**][NLL-fixed-by-NLL] labels bugs that are problems solely with the AST-borrowck -- they are bugs that we intend to close once everyone migrates over to NLL. - [**NLL-polonius**][NLL-polonius] labels bugs related to the Polonius subproject - see the Polonius working group for more information on these. [A-NLL]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3AA-NLL [NLL-sound]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-sound [NLL-performant]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-performant [NLL-complete]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-complete [NLL-reference]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-reference [NLL-diagnostics]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-diagnostics [NLL-fixed-by-NLL]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-fixed-by-NLL [NLL-polonius]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ANLL-polonius [nikomatsakis]: https://github.com/nikomatsakis [pnkfelix]: https://github.com/pnkfelix --- ### Working Groups Traits Index (`content/working-groups/traits/_index.md`) --- title: Traits Working Group type: docs --- # Traits Working Group ![working group status: retired][status] [status]: https://img.shields.io/badge/status-retired-cacaca.svg?style=for-the-badge - **Team:** [wg-traits on rust-lang/team](https://github.com/rust-lang/team/blob/master/teams/wg-traits.toml) [nikomatsakis]: https://github.com/nikomatsakis [jackh726]: https://github.com/jackh726 # Scope and purpose The **traits** working group is dedicated to improving the trait system implementation in rustc. This working group is a collaboration between the [lang team] and the compiler team. We have a number of inter-related goals: - designing new trait-related language features; - documenting and specifying the semantics of traits in Rust today; and, - improving the trait solver implementation in rustc. [lang team]: https://github.com/rust-lang/lang-team/ A big part of this work is transitioning the compiler to use a [Chalk-style] solver, but along the way we hope to make targeted fixes to the existing solver where needed. [Chalk-style]: https://github.com/rust-lang-nursery/chalk # How to participate Please take a look at our dedicated repository, [rust-lang/wg-traits] for all the details! [rust-lang/wg-traits]: https://github.com/rust-lang/wg-traits --- ### Working Groups Meta Rfc Drafts Index (`content/working-groups/meta/rfc-drafts/_index.md`) --- title: rfc Drafts type: docs --- This direction contains drafts of "Meta WG"-related RFCs. These are RFCs that pertain to compiler team process and which are being jointly written as part of the Meta working group. - [Compiler Team Contributors]({{< relref "/working-groups/meta/rfc-drafts/compiler-team-contributors" >}}) --- ### About CODE OF CONDUCT (`content/about/CODE_OF_CONDUCT.md`) --- title: Code Of Conduct type: docs --- # The Rust Code of Conduct A version of this document [can be found online](https://www.rust-lang.org/conduct.html). ## Conduct **Contact**: [rust-mods@rust-lang.org](mailto:rust-mods@rust-lang.org) * We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. * On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all. * Please be kind and courteous. There's no need to be mean or rude. * Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. * Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. * We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. * Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Rust moderation team][mod_team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back. * Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome. ## Moderation These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Rust moderation team][mod_team]. 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. 3. Moderators will first respond to such remarks with a warning. 4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off. 5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded. 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. *Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).* [mod_team]: https://www.rust-lang.org/team.html#Moderation-team --- ### About Chat Platform (`content/about/chat-platform.md`) --- title: Chat platform type: docs --- # Chat Platform The compiler team hangs out in [the rust-lang Zulip][z] these days. Feel free to introduce yourself and say hi in the [`#new-members`](https://rust-lang.zulipchat.com/#narrow/stream/122652-new-members) stream! The [`#t-compiler/help`](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp) stream is also a great place to ask questions. In addition, each working group has one or more streams where they communicate. [z]: https://rust-lang.zulipchat.com --- ### About Steering Meeting (`content/about/steering-meeting.md`) --- title: Steering meeting type: docs --- # Steering Meeting The compiler **steering meeting** is the place for high-level discussion and planning. The meeting takes place weekly. The topics of the meeting are selected at periodic planning meetings. See the [steering meeting procedure][proc] for more details. See [#58850] for more information. [proc]: https://forge.rust-lang.org/compiler/steering-meeting.html See the [compiler team calendar](../../#meeting-calendar) for the topics of the next scheduled meetings. There is also a [dedicated internals thread][internals]. [#58850]: https://github.com/rust-lang/rust/issues/58850 [internals]: https://internals.rust-lang.org/t/compiler-steering-meeting/8588 The steering meeting takes place on [Zulip](../chat-platform/). Look for a topic like "steering meeting YYYY-MM-DD" (with today's date, of course). There are [minutes from previous steering meetings][minutes] available in this repository. These minutes summarize our conversations. [minutes]:https://github.com/rust-lang/compiler-team/tree/master/content/minutes --- ### About Triage Meeting (`content/about/triage-meeting.md`) --- title: Triage Meeting type: docs --- # Triage Meeting The compiler **triage meeting** is the place for tracking regressions, progress on urgent bugs and checking-in with the compiler team's working groups. Each meeting, two working groups (rotating) check-in with their progress and blockers. The meeting takes place every week. See the [compiler team calendar](../../#meeting-calendar) for the next scheduled meeting (normally weekly). The triage meeting takes place on [Zulip](../chat-platform/). Look for a topic like "#54818 weekly meeting YYYY-MM-DD" or "weekly meeting YYYY-MM-DD" (with the proper date, of course). The regular agenda (and process for pre-triage) is maintained on [Rust Issue 54818]. [Rust Issue 54818]: https://github.com/rust-lang/rust/issues/54818 ## Working group check-in This section contains the scheduled check-ins for working groups: {{< checkin-schedule >}} --- ### Procedures Call For Participation (`content/procedures/call-for-participation.md`) --- title: Call for participation type: docs --- # Call for participation One way to get help with a project is to issue a **call for participation** on the dedicated internals thread. Such calls should follow this (very simple) template, so as to help clarify what's going on: ``` - **Title:** Investigate #123141 - **Experience level expected:** (Newcomer | Contributor | Experienced) - **Urgency:** (ASAP | over next few months | whenever) - **Contact:** @your-name-here in [the #your-stream-here stream on Zulip][z] [z]: https://rust-lang.zulipchat.com/ Longer description goes here. ``` You should feel free to substitute other text for Experience Level Expected and Urgency, but the idea is to convey our expectations to people. In particular, the Urgency field is supposed to indicate how *quickly* people would need to work on this. --- ### Procedures Crates (`content/procedures/crates.md`) --- title: Third Party out of tree crates type: docs --- # Third-party and out-of-tree crates This document describe the guidelines for creating out-of-tree crates for use in the compiler and using third-party crates within the compiler. These guidelines were originally discussed at the Rust All Hands 2019 by the compiler team and others; and then at the [01/03/2019 steering meeting][steering_meeting]. [steering_meeting]: ../../minutes/steering-meeting/2019-03-01/ ## Out-of-tree crates One of the primary goals of this policy is to ensure that there is consistency in how out-of-tree crates used in the compiler are set up (at least, those maintained by the compiler team and living in `rust-lang`) and that the experience is uniform across `rust-lang/rust` and these crates. ### When should parts of the compiler be extracted into an out-of-tree crate? This is left to the discretion of compiler team members but should be discussed with the rest of the team, either through raising the question at the weekly triage meeting or asynchronously using an FCP in an issue. If the crate is a product of a working group, there should already be agreement within the working group that an out-of-tree crate is suitable. When considering creating an out-of-tree crate, it is worth balancing how general the crate should be with the increased maintenance burden that this may bring if widely used. ### Where should compiler crates live? Out-of-tree compiler crates should be hosted in the `rust-lang` organization - this simplifies integration with external infrastructure tooling and will inherit existing team permissions on GitHub. It should be made clear in any documentation that the compiler team and any appropriate working groups are responsible for the crate. It is not recommended to start with a prototype in another organization or personal repository. ### Can existing out-of-tree crates from personal accounts or other organizations be transferred? Yes, this is encouraged. In order to do this, discuss this with the team and familiarize yourself with [the GitHub documentation for repository transfers][repo_transfers] and then arrange to perform the transfer. Once a transfer is complete, a redirect will exist in the original account or organization and this will conflict with the names of any new forks of the transferred repository - an email to GitHub is required to resolve this. [repo_transfers]: https://help.github.com/en/articles/transferring-a-repository ### Who owns these crates? It is desired that a compiler team member or working group has loose ownership over a crate so that there are clear owners who are responsible for making sure that new versions are published and that pull requests are reviewed. ### What should these crates be named? Crate naming will be discussed when new out-of-tree crates are proposed to the compiler team. Crate naming will differ on a case-by-case basis. Crates that are inherently tied to the compiler would benefit from a name that is prefixed with `rustc_`. This is an indicator of how stable the crate may be to prospective users. Other crates, which are more general-purpose, will have names that are disentangled from the compiler. ### Are there any limitations on the review policy for out-of-tree crates? Generally, the working groups and team members that are primarily free to maintain the crate using whatever practices are best suited to their group, however, there are some limitations so that there is some uniformity across the compiler and out-of-tree crates: - Everyone with r+ on `rust-lang/rust` should be able to review and approve PRs. - Where possible, only active participants in the crate (or related working group) need be on the highfive rotation for the crate. - It is fine to have additional reviewers on the crate who do not otherwise have r+ for Rust as a whole, if those reviewers are actively involved in the working group or crate maintenance. - Major pull requests should have multiple reviewers. ### What is required of an out-of-tree crate? It is required that out-of-tree crates must: - Be dual-licensed with Apache 2.0 and MIT when maintained by the compiler team (as the compiler is) unless there is a compelling reason to do otherwise. - If another license is desired, this must be brought up when proposing the new crate for compiler team members to agree. Prefer [licenses accepted by tidy][licenses], unless otherwise required (ports of code from other projects, etc). - Abide by Rust's code of conduct. - Specify that the crate is maintained by the Rust compiler team and any appropriate working groups. - In particular, this should detail the expected level of maintenance and stability for any prospective users. - This should also link to the working group details in this repository. - Be added to the list at the bottom of this page. - Follow semantic versioning. - Use `@bors` and `@rust-highfive`. - Use labels that are compatible with the existing triage process. This will allow nominated issues in your out-of-tree crate to be discussed during triage meetings. - eg. `T-compiler`, `I-nominated` (a full list is to be decided) ### Is there a requirement for community infrastructure for an out-of-tree crate? There is no requirement that community infrastructure (such as Zulip servers/streams) be created for out-of-tree crates. This may be desirable if an out-of-tree crate gains a large community of contributors and users, but otherwise, the working group or compiler team streams should be used initially. Linkifiers for auto-linking to issues and PRs on the primary Rust Zulip server can be added on request. ### Are there any recommendations for working with out-of-tree crates? Recommendations for working with out-of-tree crates will be documented in the rustc-dev-guide (see [rust-lang/rustc-dev-guide#285][guide_issue] for progress). ### How should stabilization/semantic changes be handled in out-of-tree crates? It is important to involve the language team in any changes in out-of-tree crates that would result in stabilization or semantic changes to the language. Submodule changes in PRs to `rust-lang/rust` should be labelled appropriately (eg. `relnotes`, `T-compiler`, `T-lang`) just as if the change were implemented in `rust-lang/rust` directly, include a description of the changes when it is not obvious to those unfamiliar with the compiler or the out-of-tree crate. [licenses]: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/deps.rs#L10-L19 [guide_issue]: https://github.com/rust-lang/rustc-dev-guide/issues/285 --- In summary, the process for establishing an out-of-tree crate is as follows: 1. Where appropriate, discuss and confirm the need within the working group for the out-of-tree crate. 1. Create a PR modifying this document to include the crate in the list below. Use [`@rfcbot merge`](https://github.com/anp/rfcbot-rs#usage) to gain agreement from compiler team members. 1. Create a new repository in the `rust-lang` organization. 1. Navigate to `Settings > Collaborators & Teams` and add the `Compiler` team with write privileges and `Assignees` with `read`. - Individuals that are not part of the team can be added where appropriate. 1. Add a README describing the intended purpose of the crate, which team and working group are responsible (link to their page in this repository) and the intended level of maintenance and stability. > This crate is developed and maintained by the [Rust compiler team](https://github.com/rust-lang/compiler-team/tree/master/procedures) for use within > `rustc`, in particular, it is the responsibility of the > [`.template`](../../working-groups/template) working group. This crate [will have regular > breaking changes and provides no stability guarantees|is intended to remain stable and have > limited breaking changes]. 1. Include the [LICENSE-APACHE][apache] and [LICENSE-MIT][mit] files from `rust-lang/rust`. 1. Include or link the [CODE_OF_CONDUCT][coc] file from `rust-lang/rust`. 1. Create a relevant `.gitignore` ([here's a sane default][gitignore]). 1. Create `P-high`, `P-med`, `P-low`, `I-nominated` and `T-compiler` labels. 1. Consult with the infrastructure team to set up `@rust-highfive` and a process for publishing under the "The Rust Project Developers" crates.io account. 1. Add a basic `.travis.yml`: ```yaml language: rust rust: - stable ``` - `@bors` is not normally used for out-of-tree crates, GitHub's built-in merge facilities can be used instead. 1. Perform any initial development required before integration with rustc. 1. Publish initial version, following semantic versioning. 1. Add the crate as a dependency to the appropriate in-tree crate and start using. [gitignore]: https://gitignore.io/api/vim,rust,emacs,clion,visualstudio,visualstudiocode [triagebot]: https://github.com/rust-lang/rust/blob/master/triagebot.toml [apache]: https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE [coc]: ../../about/code_of_conduct [mit]: https://github.com/rust-lang/rust/blob/master/LICENSE-MIT ## Third-party crates It is sometimes desirable to use the functionality of an existing third-party crate in the compiler. ### When can a third-party crate be added as a compiler dependency? It is desirable that a third-party crate being included in the compiler is well-maintained and that, where possible, a compiler team member is added as a maintainer. You should consult with the rest of the compiler team before making this decision. ### What about third-party dependencies to out-of-tree crates? The same policies apply to all compiler-team-maintained crates used in the compiler. ## List of out-of-tree crates This section contains the list of existing out-of-tree, compiler team-maintained crates: - [`rust-lang/chalk`](https://github.com/rust-lang/chalk/) - [`rust-lang/polonius`](https://github.com/rust-lang/polonius/) - [`rust-lang/measureme`](https://github.com/rust-lang/measureme/) --- ### Procedures Form New Working Group (`content/procedures/form-new-working-group.md`) --- title: Forming a new working group type: docs --- # Forming a new working group So, you would like to form a working group? ## Step 0. What *is* a working group? Working groups are the basic way that the compiler team tracks what is going on. **If you are doing some sort of task that the compiler team will want to track over time, then it makes sense to form a working group**, even if you don't plan to be getting more people involved. **The compiler team regularly checks in on the progress for each active working group.** So every working group should always have at least one person who attends the compiler team triage meetings and is willing to produce those regular updates. ## Step 1. Propose the working group **TBD** -- ironically, we haven't *quite* decided what the procedure is for this! For now, a good idea is to hop on to [#t-compiler][cp] on [the Zulip][cp] and open up a new topic to discuss your idea. Or, alternatively, join a meeting and leave a few comments. [cp]: ../../about/chat-platform A good goal for this process is to try and identify a small number of **achievable deliverables**. It will be easiest to manage a working group if you have relatively clear, finite goals. Don't worry if you seem to be tackling an "infinite" problem space -- set some initial goals within that problem space. If, after you achieve those, you wish to continue, you can always add fresh goals or (maybe better) form a new working group. It's also good to identify an initial set of **group leads** -- the leads are the people who are driving the project forward overall. It's best if you have 2 or 3 leads who are excited about the project, including at least one person from the compiler team, but there aren't strict rules here. See below for a few more details. ## Step 2. Figure out key information You need to decide the following: **Who are the leads?** The leads are the people who are ultimately responsible for ensuring that the working group is making progress and for reporting on that progress to the compiler team and community as a whole. Basically, they are the people who are **driving** the project forward. **The set of leads can also change over time.** Often, as new people join, they may start to play a leadership role, which is great! Leads often do the organizational work for the WG: - scheduling meetings - summarizing progress from the meetings into reports - reporting to the compiler team but these jobs can (and should, where possible) be delegated amongst the team as well. When possible, we prefer to have 2 or 3 leads per WG. 1 lead is ok, but not recommended, as it can be stressful. While not strictly required, typically at least one lead should be a full member of the compiler team. **Will you have a regular meeting?** If so, when? You can always change this later, of course. Many working groups opt for a weekly meeting held on Zulip. **Are you willing to do the work?** Serving as a working group lead typically means not only writing code, but also helping to do the planning and serving as a mentor to participants. It can be a lot of work sometimes! But it's very rewarding. ## Step 3. Setting things up The basic steps to setup a working group are as follows: - **A stream on Zulip:** contact someone on [#t-compiler][cp]. - **A 'user-group' on Zulip:** For most working groups, we create a [Zulip][cp] "user group", which is basically an alias that people can be added to for easy notifications. - **A team in the github org:** Some groups create a team in the github org. You can then add working group participants into this GH team and give the team permissions on the rust repository or other repositories. Note that only `rust-lang` organization members can be added to the group and being part of a working group is not enough reason to add people to the organization right now. - **Updating this repository:** This repository serves as the central home for working groups, so it needs to be updated. Make the following changes and then open a PR against the repository (make sure to leave a note in [`#t-compiler`][cp], as these PRs can be easily overlooked): - Add the working group to the table in the [main page][main_page]. Feel free to put N/A for any column that doesn't seem to apply. - Add a subdirectory to the [`working-groups`][working_groups] directory. You do this by copying the [`template`]({{< relref "/working-groups/template/_index.md" >}}) directory to a directory of your own and modifying its contents as appropriate. Feel free to remove sections if they don't seem to apply: many working groups start out with relatively little structure but define it early on. - Add the working group to the check-in schedule by modifying `layouts/shortcodes/checkin-schedule.html`. - **Add an entry to the compiler team calendar:** If you have a regular meeting, ping somebody on [`#t-compiler`][cp] to add an entry to the compiler team calendar. - Add a file to the [`rust-lang/team`][team_repo] repository. Only working group leads should be listed and a link to their directory in this repository should also be included. See the traits working group [as an example][team_repo_example]. This will ensure that the working groups are listed on the website. - Add a check-in for your working group to the [`compiler-team meeting check-in list`][check_in] [team_repo]: https://github.com/rust-lang/team [team_repo_example]: https://github.com/rust-lang/team/blob/master/teams/wg-traits.toml [check_in]:../../about/triage-meeting/ [main_page]: ../../ [template]: ../working-groups/template/_index [working_groups]: https://github.com/rust-lang/compiler-team/tree/master/working-groups --- ### Procedures Steering Meeting (`content/procedures/steering-meeting.md`) --- title: Steering meeting type: docs --- # Steering meeting This content has moved to the [Rust forge](https://forge.rust-lang.org/compiler/steering-meeting.html). --- ### Minutes Design Meeting 2019 06 21 The Gcx Tcx Transition (`content/minutes/design-meeting/2019-06-21-the-gcx-tcx-transition.md`) --- title: Planning the gcx, tcx transition type: docs --- # Planning the `'gcx, 'tcx` transition - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019.2E06.2E14) # Summary - Discuss the end-state for `tcx` - Plan the steps we will take to get there and time frame # Motivation Now that we have removed the per-inference context interners, we plan to transition the compiler to a different naming scheme. This is a major shift and something we should plan carefully. Also, it's an opportunity to consider an alternate naming scheme -- `tcx` and `'tcx` is not known to be particularly popular. # Details ## Names for tcx - Given the new, query-focused compiler design, there have been proposals to rename tcx to something like `QueryCx`. The lifetime name `'tcx` is also not particularly evocative. - One obvious proposal would be `qcx` and `'qcx` though this is not obviously better. - `q: QueryContext<'query>` or something like that is also viable though longer - (eddyb) `qx: QueryCx<'q>` (if we want to make it about queries) - `db: RustcDb<'db>` (if we want to go the salsa route) ## Transition plan eddyb has a plan I sort of understand: - ~~transition `TyCtxt<'_, 'tcx, 'tcx>`-using code first, to `TyCx<'tcx>` (name doesn't matter as long as it's unique for easy replacement later)~~ - ~~then start moving `'gcx,'tcx` code one InferCtxt user at a time, by making InferCtxt creation allow both `'tcx,'tcx` and `'gcx,'tcx`~~ - **UPDATE**: brute force was easier: https://github.com/rust-lang/rust/pull/61817 (see PR description for how it was done) - what's left to discuss is whether we want this solution There are some question marks around timing: - What will it be like to rebase a major PR over these changes? - Any major PRs outstanding we want to block on? # Challenges - Bikeshed :) # Key design questions Unclear # Notes from meeting - PRs thus far: - ban unused lifetimes: [#61735](https://github.com/rust-lang/rust/pull/61722) - remove the `'a` [#61722](https://github.com/rust-lang/rust/pull/61722) - centralize to `TyCtxt<'tcx>` [#61817](https://github.com/rust-lang/rust/pull/61817) - Create [#61838](https://github.com/rust-lang/rust/issues/61838) to serve as a tracking issue - So, to make the transition: - generally rewrite `TyCtxt<..>` to `TyCtxt<'tcx>` or `TyCtxt<'_>` - typically, rewrite `TyCtxt<'_, '_, 'tcx>` to `TyCtxt<'tcx>` - note that if you have `TyCtxt<'_, 'tcx, '_>`, rewrite to `TyCtxt<'tcx>` - replace unused lifetimes with `'_`, typically - note: when adapting your code, you should never need to introduce a new lifetime, you're only removing them - if you find yourself adding a `'gcx` to some impl, that's wrong =) - Possible future naming: - We are not thrilled with `TyCtxt<'tcx>` and are considering some alternatives: - `qx: QueryCx<'q>` - couple with `x` being the suffix we use for "contexts" in general (this convention was adopted in trans, but not elsewhere) - `db: RustcDb<'db>` (or perhaps `db: Database<'db>`) - used in salsa, it's the central storage for compiler state; but there are concerns that db doesn't fit "computation" - if we do more modules, then `RustcDb` might also be `ParsingDb` (for parsing-related queries), `TypeckDb` (for type-related queries), etc - though there are some impl concerns around that; salsa style modules do impose - dyn dispatch for each call, even cache hits; or, - monomorphization costs - `rs: Rust<'rs>` - `rx: Rust<'rx>` - this is the "rust compiler", so maybe that should be the basis of the name? - `s: Session<'s>` - related to existing `tcx.sess` - session of "what"? - Reasoning to change: - tcx is sort of cryptic, can we find a name that gives people a better intuition? - the name "tcx" suggests "type context", but this context is far more general and is used in parts of the compiler (e.g., parsing, macros) that have nothing to do with types - Conclusion on naming: - let's let it sit for a bit, not high priority --- ### Minutes Design Meeting 2019 07 08 Triage Wg (`content/minutes/design-meeting/2019-07-08-triage-wg.md`) --- title: Triage Working Group Discussion type: docs --- # Triage Working Group Discussion - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05) # Summary - Discussed ideas of a triage working group and how that might interact - Discussed pnkfelix/nikomatsakis taking leave over next few weeks and what to do in the meantime - Discussed the problems around review queues # pnkfelix/nikomatsakis absence pnkfelix will be going on parental leave for 2 months starting July 15. nikomatsakis will be on PTO for a month or so, with limited availability. In the interim, nagisa has volunteered to run meetings. Another concern was the general review backlog. pnkfelix/nikomatsakis discussed spending a bit of time triaging things that need review and trying to develop a plan. In general, we noted that it would be useful to keep a calendar on [the compiler-team repository][ctr] to help track this sort of thing. [ctr]: https://github.com/rust-lang/compiler-team # Triage plan In general, the compiler triage effort is feeling pretty stretched. It also falls largely on a few people at this point in time. We discussed how we might broaden the effort. ## The work of solving a regression [Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169713350 Most errors come in the form of regressions: something that used to compile or run, but no longer does. One observation is that the work of handling a regression is actually something you can break down into many steps: - Figuring out the impact of the bug and assigns priority - Coallescing duplicates - Determining the cause of the regression: we have a tool that bisects to a nightly or even a specific PR, but somebody has to run it - Minimizing the error case into a standalone example that can be debugged - Identifying the *expected behavior* of the test case -- sometimes the regression comes from a bug **fix**! - Actually fixing the bug The final two require some amount of expertise -- though the precise amount varies. Today, there are a lot of people who help and do the minimization and bisection work, but it would be great if we could help organize those efforts more. ## The ICE-breakers [Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169713884 The next thing is one we've kicked around for a while -- can we create some kind of "ICE-breaker" group that is dedicated to fixing regressions, ICEs, and other "small" bugs in the compiler? What overlap does that group have with the triaging efforts described above? We discussed this for some time and seemed to come roughly to the following conclusions: - The [#wg-triage effort in the release team][wg-triage] obviously overlaps a lot with these efforts. - Perhaps we should divide responsibility as follows: - wg-triage: - decides what is important to fix or address based on the impact - helps to bisect, minimize, and identify the source of problems - brings it to compiler team attention and checks on progress regularly - tries to find assignees -- this will require compiler team participation! - compiler-team: - does the actual fixing - Note that if wg-triage is going to find out who to assign to a bug, that is going to require compiler team participation. We could in tricky cases have a "liason" who can be assigned that has the job of just reassigning to someone more appropriate. - On compiler side, the ICE-breakers group might still exist as well, and many of its members would likely participate in the wg-triage effort, but the focus of ICE-breakers would be mostly on the actual fixing of the bug, and less on the bisection and so forth. [wg-triage]: https://www.rust-lang.org/governance/teams/operations We concluded ultimately that we should try to touch base with the wg-triage effort and discuss. ## Expert map, reviewing load [Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169715908 We have an [expert map] on the compiler-team repository, but it is sparsely populated and doesn't include the new compiler team contributors. That would be in principle be helpful in finding people to assign to fix regressions or to review PRs. We also discused how contributors, even if they don't know an area well, can still be assigned to do a preliminary review or fix. We need to improve the "expert map" to be more complex and also to include "levels of knowledge". Perhaps rename it to "knowledge map" or something like that. Also, this can be a great way to figure out things that need to be added to the rustc-dev-guide. [expert map]: https://github.com/rust-lang/compiler-team/blob/master/experts/MAP.md ## Nomination labels [Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169715099 We spent a bit of time discussing how the `I-nominated` tags are not sufficiently precise -- at minimum, they should identify the team, but perhaps also have more information. ## Action items Emerging from this meeting: - Extend expert map with member/contributor levels - Create a compiler-team PTO calendar where people can note their upcoming absences - Join discussion with #wg-triage --- ### Minutes Design Meeting 2019 09 13 Rust Analyzer And Libraryification (`content/minutes/design-meeting/2019-09-13-rust-analyzer-and-libraryification.md`) --- title: rust-analyzer and libraryification type: docs --- # rust-analyzer and libraryification - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13) - Proposal issue: [rust-lang/rust#160](https://github.com/rust-lang/compiler-team/issues/160) - Additional notes: [hackmd document](https://hackmd.io/_ixQrAr5TKafV9m8eSU_VA?view) # Summary Goal of the meeting is to update on rust-analyzer plans and discuss taking the next step towards extracting "standalone libraries" that can be shared between rustc and rust-analyzer. ## Update on rust-analyzer Rust-analyzer has [made big strides](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175627272) and now includes - name resolution - a partial type checker - preliminary integration with chalk for trait solving - as well as a shared lexer with rustc ## What does library-ification mean? The goal is not just to create multiple crates, but to **identify reusable components that could be combined to build new tools, new compilers, etc.** Some guidelines we came up with: - separating out the IR definition from the logic - trying to separate infrastructure (e.g., the query system "plumbing", or diagnostic printing) - trying to draw boundaries that let us express tests as "input files", ideally ones that are independent from the details of the implementation, which are expected to change - the crates should hande cases like [invalid or incomplete AST](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175630428) Note that it [is ok for these libaries to depend on one another](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175629334), but we would [prefer to keep the dependencies rather shallow](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175629771), and where possible [to split out IR definition from logic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175629853). ## Testing The [distinction between unit/integration tests](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628172) comes into relief here. We want to avoid tests that will bitrot too easily, and yet one of the advantages of separate libraries is the ability to write more targeted tests. One way to help with this is to have our libraries support ["something like LLVM's model, where everything is a transformation from data to data"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628482). [This can make unit tests more stable](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628498). [Chalk kind of works like this,](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628667) and [we are experimenting with taking advantage of this in rust-analyzer](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628698). ## Some contested topics **Stable vs nightly.** rust-analyzer prefers everything to build on stable, [to make contribution easier](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175627657). However, nightly builds [enable dogfooding](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175627843), though we must be careful drawling too many lessons from that because [compilers are an unusual use-case](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175627848) ([but sometimes that's enough](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628012)). **Mono. vs poly repo.** Mono repos make it easier to make "atomic" commits. They may make it [easier to audit the effects of language changes](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175628271). A lot depends ultimately on workflow. Polyrepos enable us to [sidestep bors queue times](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175627863). We didn't definitely settle much here, except that there is [no reason to rush to polyrepos](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175630946): particularly when extracting libaries from rustc, we should stick with a monorepo setup until things mature. ## Initial libraries We discussed a bit three possible places to start: - lexer/parser - name resolution - traits + type constraint solving We concluded that name resolution would be nice, but we don't have anyone to spearhead that project right now. The meeting also included a fair amount of discussion about the specifics of what lexer/parser extraction might mean ([starting around here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-13/near/175631511)), which eventually moved to a [separate Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/frontend.20library-ification). --- ### Minutes Design Meeting 2019 09 20 Target Tier Policy (`content/minutes/design-meeting/2019-09-20-target-tier-policy.md`) --- title: Target Tier Policy type: docs --- # Target Tier Policy - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-09-20) - Proposal issue: [rust-lang/rust#166](https://github.com/rust-lang/compiler-team/issues/166) - [Original proposal with history](https://gist.github.com/joshtriplett/40191791541ea2a3d61b7fe1d381a0e7) # Summary We should have an official, objective policy for adding new (tier 3) targets, and for raising targets to tier 2 (with rustup builds) or even tier 1. Conclusion: Josh to revise policy based on feedback (done, see below) and subsequently submit as an RFC. # Motivation Rust developers regularly implement new targets in the Rust compiler, and reviewers of pull requests for such new targets would like a clear, consistent policy to cite for accepting or rejecting such targets. Currently, reviewers Rust developers regularly ask how they can raise an existing target to tier 2 (and in particular how they can make it available via rustup), and occasionally ask what it would take to add a new tier 1 target. The Rust project has no clear policy for target tiers. People not only don't know, they don't know who to ask or where to start. (See https://forge.rust-lang.org/platform-support.html for more information about targets and tiers.) # Details Straw proposal for each tier, from simplest to most complex: ## Tier 3 target policy At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. - No central decision is required to add a new tier 3 target. Reviewers may always use their own best judgment regarding the quality of work, and the suitability of a target for the Rust project. - If a reviewer wishes to consult a broader team for additional guidance, they should contact the compiler team. - If a proposed target or target-specific patch substantially changes code shared with other targets (not just target-specific code), the reviewer should consult the compiler team. - If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for a similar CPU or OS should not gratuitously use an inconsistent name for that CPU or OS. Targets should normally use the same names as used elsewhere in the broader ecosystem (such as in other toolchains), unless they have a very good reason to diverge. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. - Where possible, tier 3 targets may wish to provide documentation for the Rust community for how to build and run tests for the platform, ideally using emulation. - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that suggests a block on the PR based on the target. (A PR author may choose to help with a tier 3 target but is not required to.) - Patches adding or updating tier 3 targets must not break any existing target. - If a tier 3 target shows no signs of activity and has not built for some time, and removing it would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to people who have previously worked on the platform, to check potential interest. ## Tier 2 target policy At this tier, the Rust project guarantees that a target builds, and will reject patches that fail to build on a target. Thus, we place requirements that ensure the target will not block forward progress of the Rust project. - Any new tier 2 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the target into CI, and the CI-related requirements. This review and approval will typically take place in the PR adding the target to CI. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers on call to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. (This team should in almost all cases have at least 2 developers.) - The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers may be expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target. and are not expected to provide target-specific implementations for every tier 2 target. - Where possible, tier 2 targets should provide documentation for the Rust community for how to build and run tests for the platform, ideally using emulation. - The target development team should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the target. - The target must build reliably in CI. - Building the target must not take substantially longer than other targets. - Tier 2 targets must support building on the existing targets used for CI infrastructure. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that suggests a block on the PR based on tests failing for the target. (A PR author must not break the build of a tier 2 target, but need not ensure the tests pass for a tier 2 target, even if notified that they fail.) - The target development team should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion. - A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to people who have previously worked on the platform, and will be communicated widely to the Rust community before being dropped from a stable release. - All tier 3 requirements apply. Note: some tier 2 platforms additionally have binaries built to run on them as a host (such as `rustc` and `cargo`). Such a platform must meet all the requirements above, and must additionally get the compiler and infrastructure team to approve the building of host tools. ## Tier 1 target policy At this tier, the Rust project guarantees that a target builds and passes all tests, and will reject patches that fail to build or pass the testsuite on a target. We hold tier 1 targets to our highest standard of requirements. - Any new tier 1 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the target into CI, and the CI-related requirements. This review and approval will typically take place in the PR adding the target to CI. - In addition, the release team must approve the long-term viability of the target, and the additional work of supporting the target. - Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production users of Rust across multiple organizations or projects. A tier 1 target may be demoted or removed if it becomes obsolete or no longer meets this requirement. - The target must build and pass tests reliably in CI. - Building the target and running the testsuite for the target must not take substantially longer than other targets. - If running the testsuite requires additional infrastructure (such as systems running the target), the target development team shall arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. - Tier 1 targets must provide documentation for the Rust community for how to build and run tests for the platform, using emulation if possible, or dedicated hardware if necessary. - A tier 1 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be communicated widely to the Rust community, both when initially proposed and before being dropped from a stable release. - All tier 2 requirements apply. --- ### Minutes Design Meeting 2019 09 27 Place Interning (`content/minutes/design-meeting/2019-09-27-place-interning.md`) --- title: Place Interning type: docs --- # Place projection interning meeting 2019-09-27 [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Place's.20projection.20interning.20design.20meeting.20.3F) ## Ideas to pursue at some later point or in parallel - removing the field from the projections - get rid of static from `PlaceBase` - I (oli-obk) think this would be good to pursue ealier than later since it'll just eliminate an annoying piece that we don't really care about most of the time - intern entire places at the MIR level - interning `(base, Vec)` means less re-use overall though - nice hack: rfirst 128 (eddyb suggests 2^16) locals or so can be mapped to themselves - could even be extended for whatever the most common projections are if that proves useful - insert gratuitous reference to random compression methods here ## Ideas rejected - intern the `Vec` to a `&[Projection]` - **Rejected:** List is better because it is smaller, and we can use a `PlaceRef` for cases where you want to do subslicing - Although `&[Projection]` would mean that `a.b.c` and `a.b.c.d` could sometimes share memory, if we were clever enough ## Candidates to pursue first - intern the `Vec` to a `List` (probably the right first step) - challenges: - construction - `MutVisitor` - intern the `Vec` to a per-MIR integer (unlikely to be the first first step) - maybe we can retain `MutVisitor` in its current design if MIR still owns the `Projection` arrays - maybe an interesting intermediate step to start from, as it removes one of the challenges, and just leaves us with construction - but it comes with its *own* challenges, like now you can't just take a `Place` and get its data without a MIR (you have to do `mir.projection_data(index)`) But both of these require tweaking construction. ## Construction General place for modifying MIR building is to convert to a `PlaceBuilder`, as outlined [in this Zulip comment](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Place's.20projection.20interning.20design.20meeting.20.3F/near/176746025). We need to work out the precise steps to do this, and we may want to do some efficiency tweaks like `SmallVec` to avoid iterating in the common cases. This is also something [we can pursue before doing *any* interning](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Place's.20projection.20interning.20design.20meeting.20.3F/near/176747691), so it's the logical next step. --- ### Minutes Design Meeting 2019 10 04 Roadmap 2020 Goals (`content/minutes/design-meeting/2019-10-04-Roadmap-2020-Goals.md`) --- title: Roadmap 2020 type: docs --- # Roadmap 2020 Compiler Discussion [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-04) # 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](https://poll.ly/#/P76nbdyb) -- 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-04/near/177342591)) * rough conclusions * bootstrap is worth focusing on * codegen time is a big deal * [measurements suggest](https://mark.rousskov.org/parallel-compiler-data/master/rustc-compiler-opt-timing.html) librustc is long pole in the tent, also * 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-04/near/177344654): * 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 * [2019 roadmap](https://raw.githubusercontent.com/rust-lang/rfcs/HEAD/text/2657-roadmap-2019.md) * [random brainstorming by pnkfelix + nikomatsakis](/iHCbm2sWQ-y2KuWFjEpUog) --- ### Minutes Design Meeting 2019 10 11 DepGraph Persistence PR62038 (`content/minutes/design-meeting/2019-10-11-DepGraph-persistence-PR62038.md`) --- title: Dep-graph loading (#62083) type: docs --- # design meeting 2019-10-11 [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11) ## introduction Dear @*T-compiler/meeting*, Today we will be having a **design meeting**. The topic was originally sketched as "some Zoxc PR". We've since narrowed that down to discuss #62038, which is a refactoring to how dep-graph loading occurs. @**Zoxc** [wrote up a comment](https://github.com/rust-lang/rust/pull/62038#issuecomment-540508308) giving a summary of the ideas. Note that this PR itself is an incremental step towards #60035, which aims to make dep-graph loading/saving more continuous. I'd also like to discuss briefly how we should document these changes. We currently have some rustc-chapters on incremental compilation (e.g., [this chapter goes into detail](https://rustc-dev-guide.rust-lang.org/queries/incremental-compilation-in-detail.html)). I would like to move us to a world where major refactorings like #60035 (but not limited to this one -- I think e.g. [my recent PR](https://github.com/rust-lang/rust/pull/65232) and work on lazy norm fits the bill) come along with a rustc-dev-guide chapter that documents the new state of the world. Maybe we discuss some how that might work and -- in the case of THIS PR -- who might do that documentation work (I don't necessarily think it has to be @**Zoxc**, though they're also an obvious candidate). (In my ideal world, drafts of that chapter would be available *before* the PR, but at minimum I think such a chapter should be in place to help with reviewing.) ## Questions for discussion * "This is where the performance gain of this PR is.", have we measured this at all? -- nikomatsakis * [Here are some measurements](https://perf.rust-lang.org/compare.html?start=4a365a29d64bec75d107214319a129ba68fc12a3&end=7830caefb62c9c8d3fb7a742c66c64c89bf3aafe&stat=wall-time). However, are they done against a single-threaded or parallel compiler? -mw * The results show some improvements and some regressions. * "The one possible performance drawback is that ids can become fragmented since this PR requires us to reuse ids from the previous session." -- in what way is this a performance drawback? Do we have any mechanism to reuse ids or 'reset' state after a suitable amount of time? * There is another possible performance drawback: The current dep-graph has to be built two times in the worst case (i.e. full cache, but all invalid). Is that correct? ## Minutes and notes from discussion * Review of how existing dep-nodes work * [Discussion about the color scheme](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177910369) * [Brief notes about parallelism](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177910794) * [Notes on how dep-graph works today](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177911022) * Questions about the PR * [Key idea: change is to load up the old graph and use it as the starting point, editing it in place, rather than copying things out from it into the new graph](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177911184) * [Deleting nodes and garbage](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177911307) * when we load nodes, they have no color * if at the end of compilation they still have no color, we can delete them * we keep a "free list" for indices so they can get re-used * However: * we never shrink the graph as a whole, so if there used to be a lot of ids, we will keep the graph the same size * [in particular there could be an exceptional execution that creates a lot of nodes](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177912057) * ids may also become fragmented over time * [How could we address this?](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177912273) * some form of "compression" step when writing back to disk * complication: query-result-cache uses ids as keys * ["if we want to garbage collect them, it must be done in sync with the query result cache"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177912399) * [Conclusions](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-11/near/177915151) * We had a good discussion of the PR in question. I don't think we raised any red flags or anything, the approach seems solid. * The real question is whether we want to move in he **overall direction** proposed by #60035 * The goal here is to reduce the cost of loading/saving the dep-graph * #60035 proposed to do so by incrementally dumping out changed nodes and not retaining them in memory * This we barely touched on -- some open questions for me * Are there alternative designs we have in mind? * Is #60035 itself an "end state" or a stepping stone? * Conclusion: * Follow-up meeting to dig into design of #60035 and maybe discuss alternatives * In parallel, Niko will review #62038 now that he understands roughly what it is trying to do * We would also want to write docs for rustc-dev-guide * We can figure out how that happens in parallel --- ### Minutes Design Meeting 2019 10 18 Debuginfo Meeting (`content/minutes/design-meeting/2019-10-18-debuginfo-meeting.md`) --- title: Debugging Support type: docs --- # Debugging Support in the Compiler * [Zulip stream][] or read on the [Zulip archive][] [Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-18/near/178475282 [Zulip archive]: https://zulip-archive.rust-lang.org/131828tcompiler/13652designmeeting20191018.html ## The problems https://github.com/rust-lang/rust/issues/64343 We have bugs with debuginfo that are causing broad pain for people who use x.py test, but we do not have dedicated developers who own maintenance of debugger support. https://github.com/rust-lang/rust/pull/60826 We have Pull Requests to improve our debuginfo support, but we do not have dedicated developers who own maintenance of debugger support. Q: Are we willing/able to maintain debuginfo stuff Q: if we don't, then can we afford to keep these tests? In short, as Niko said: "we need help to maintain this or we may have to remove it" ---- The overarching goal was to discuss how we can get a sustainable story than the particular issues themselves, though that may also be a topic of discussion. * what steps can we do to recruit folks * what are some thresholds and timelines where upon we consider more drastic action * what might that drastic action be :) ## The meeting some of the main points from the discussion: * a common refrain: most of the compiler developers know next to nothing about how the debugger support scripts are implemented. So we are not in a good position to maintain the debugger support scripts. * @eddyb has ideas for how we might try to shift functionality out of the debugger support scripts and instead "handled it through traits and codegen" (?) * debuginfo tests are effectively unmaintained because everyone has their own ways of ignoring the failures * We should add // ignore to the problematic tests in the short term (but make sure to associate any such ignore with a rust-lang/rust issue). * we might want to split the tests into debuginfo and debugger-pretty or something; the debuginfo stuff we must keep working, while debugger-pretty are more "nice to have" bits of functionality --- ### Minutes Design Meeting 2019 11 01 Streaming Dep Graph Proposal (`content/minutes/design-meeting/2019-11-01-streaming-dep-graph-proposal.md`) # "Streaming dep graph" proposal ## Summary of the proposal Currently, incremental compilation begins by loading the old dependency graph and then -- as execution proceeds -- building a new dependency graph in memory. At the end of compilation, this new graph is written out. PR [#60035] proposes to change how the new graph is handled. Instead of building the graph in memory and writing it out at the end, we "stream" out a series of changes to the dep-graph as we go. When parallel compilation is enabled, this streaming can proceed in a background thread. ### Advantages This has the following advantages: * Lower peak memory usage * e.g. style-servo-check has a 30% reduction in memory usage in the [May 7th perf results][perf-may-7-max-rss] and there are no cases of memory usage increasing * Avoids blocking on writing out the dep-graph at the end of compilation, which improves performance, especially for smaller compilations * the magnitude here is a bit unclear * the [May 7th perf run][perf-may-7] shows up to 8% regressions in instruction count, but up to 5% wins in CPU time (and wallclock time), perhaps related to parallelism? --Niko. That is because loading the dep graph is slower, but it happens on a background thread. * Avoids the work of re-writing unchanged portions of the dep-graph. * (pnkfelix notes that in the most extreme cases, e.g. of rebuilding a touched but unchanged files, this can be significant.) [perf-may-7-max-rss]: https://perf.rust-lang.org/compare.html?start=eeedd3a6e15d43d0cd3e860f36be737cb2c941ca&end=cfe977fc791e1a9305d2b79e47b448dfa50abb4a&stat=max-rss Dicussion of goals from Zulip conversation: * [starts around here](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179630511) * writing out the dep graph occurs in parallel with LLVM right now * but if there is nothing for LLVM to do, that doesn't help * [clean incremental runs ought to be "worst case" measurements for current system](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179631067) * no changes, nothing for LLVM to do to mask latency * existing measurements suggest: * up to 30% wins for peak memory usage -- example, style-servo-check * [up to 9% wins for CPU](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179631529) -- example, regex * motivating example: * unused-warnings-check, where clean incremental costs more than clean ## PR Thread Some key comments from the PR thread (which is long) * perf comparisons (I'm not sure on the differences between these -Niko) (Only the last one has a GC, but I don't think that perf triggers that anyway. Also the PR is still WIP so perf is probably not completely representative -Zoxc) * [perf comparison from Apr 17][perf-apr-17] * [perf comparison from Apr 20][perf-apr-20] * [perf comparison from Apr 22][perf-apr-22] * [perf comparison from May 7][perf-may-7] * [mw expresses concerns][mw] * generally, that the change looks potentially quite good, but adds a lot of complexity, and we need to have good docs and more discusion -- this meeting is part of that! * [nnethercote advocates in favor on the basis of memory usage][nnethercote] * "A Firefox developer was complaining recently that compilation of Stylo within Firefox was causing OOMs because memory usage was exceeding 3.5 GiB. I did some profiling runs with Massif and DHAT, and for incremental builds the dep graph dominates the memory profiles -- most of the top entries involve the dep graph." [perf-apr-17]: https://github.com/rust-lang/rust/pull/60035#issuecomment-484182697 [perf-apr-20]: https://github.com/rust-lang/rust/pull/60035#issuecomment-485084601 [perf-apr-22]: https://github.com/rust-lang/rust/pull/60035#issuecomment-485478028 [perf-may-7]: https://github.com/rust-lang/rust/pull/60035#issuecomment-489976439 [mw]: https://github.com/rust-lang/rust/pull/60035#issuecomment-497641996 [nnethercote]: https://github.com/rust-lang/rust/pull/60035#issuecomment-513986697 [#60035]: https://github.com/rust-lang/rust/pull/60035 ## Questions regarding implementation ### What does the on-disk and in-memory format of the data look like? A great answer to this question would be something that can be used as module-level documentation for https://github.com/rust-lang/rust/blob/master/src/librustc/dep_graph/serialized.rs In particular, if we are only saving updates, do we have to do more work each time? We do have to do more work when loading the dep graph as garbage is accumulated. How do we collect old data? * [Zulip discussion from meeting starts here](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179628890) * [On-disk format is a list of actions](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179629046) * each `Action` is read in and "applied" to an empty dep-graph when rustc starts * note that some actions may overwrite the effects of previous actions * [comment](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179629175) * How do we manage the allocation of edge vectors? * current PR uses `Box<[Index]>` to store edges, but this can be wasteful * old approach of using a single vector of indices was efficient but hard to update * but we could just waste the space and rely on a GC * could move to arena allocation (e.g., `&'tcx [Index]`), though it shares some downsides with edge vector * Maybe we can [read the data in *backwards* to avoid the update?](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179630107) * maybe, would have to work on the serialization format * currently using LEB128 but this is not obviously the best * and there were some speedups from avoiding it elsewhere ### What form of garbage collection do we do As we are storing updates, there can be garbage data of two kinds: * Graph nodes that were overwritten with a new set of dependencies in the latest compilation * Graph nodes that were never used in the latest compilation (e.g., type-checking nodes for functions that were deleted) How do we remove these two kinds of old nodes? Is this mechanism conservative or precise? The garbage collection algorithm reads the dep graph and records the location of information we want to keep. It then clears the file and writes only the useful information back. It is precise and happens in the background thread. The cost of garbage collection is similar to loading the dep graph, so it's unlikely we'll block on it. * [discussion in Zulip around here](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179631874) * current GC just removes actions from the list of actions * it does not compress `DepNodeIndex` ranges * this implies that the size of the graph will grow if fragmentation occurs * but we do make an effort to re-use dep-node-indices * GC comes after loading and become new actions can be appended * full pipeline including GC ([link](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179632407)) * but [how do we remove "unreachable" nodes?](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179632559) * [they wind up with no red/green color at the end of compilation](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179632665) * and [we can iterate over the nodes and "remove" those that have no color](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179632721) ## Tradeoffs ### What will happen if/when we want to move to a rust-analyzer like model, with live updates? It seems like this model is just incompatible with that. I think this implies that we would want multiple 'modes' of operation. Does this model imply an in-memory dep graph only? -Zoxc ### Are there performance regressions to be expected with this approach? There's a possibility of dep node indices getting fragmentated. This is shared with [#62038](https://github.com/rust-lang/rust/pull/62038). ### Are file sizes in the same ballpark as before? They start in the same ballpark and will grow from there. We can control how large they grow by how often we run the GC. We can also throw in some compression to get then down further. We won't have to pay for the cost of compressing the entire dep graph each time, only changes. We still have to decompress the entire thing, but that happens in the background thread. ### Have other approaches been evaluated? What are they? One obvious alternative would be to stream the entire graph as it is updated, and not deltas. This sidesteps the GC issue, but has the same shortcomings as our current approach when it comes to 'partial updates'. I think this PR started out as this, but then it grew a bit -Zoxc * mw raised an idea in the design meeting ([link](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-01/near/179632896)): * (I'd be interested in how an alternative approach (that also does DepNodeIndex compaction and graph node GC) does: Still rewrite the whole dep-graph, but "stream" it to disk in the background. That should be doable with minimal changes and might have most of the benefits.) ### Is there an approach that enables less processing being needed? Perhaps storing a list of where dep node indices are stored in the file. That would allow the loading to skip to the relevant parts of the file and avoid the garbage slowing down as it accumulates. ## Future features ### Does this approach scale to partial updates of the dep-graph? Definition: "Partial updates" refers to smaller incremental runs that don't re-perform the entire compilation. This can occur in the case of compilation errors. It also occurs in an IDE scenario, where e.g. the latest query may be to find the completions at a particular point. The challenge here is that there may be parts of the previous compilation that were not required for the particular query that was just executed, but which would still be worth caching in the future. Our current setup doesn't handle this case. I don't see a reason why not -Zoxc ## Open Questions * [how much of a problem is dep-node index fragmentation?](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179633355) * does this resolve the perf issues around unused-warnings performance that [pnkfelix described?](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179631644) * is there a "reasonably small diff" that modifies current design to stream out graph and gets a lot of the benefits, as [mw suggested here](https://zulip-archive.rust-lang.org/131828tcompiler/85965designmeeting20191101.html#179632833)? * the basic idea would be: instead of building the new dep-graph in memory and encode it in the end, have a background thread that we send new nodes to and the writes them to disk. Everything else would be the same: The entire file would be re-written, including the unchanged parts. The on-disk format would maybe change in that there would be a seperate file for each of the 4 arrays in SerializedDepGraph, so they can grow independently. Alternatively (but this might be a bigger change), there would only be a single file with variable sized (DepNode, Fingerprint, [DepNodeIndex]) entries. * this approach should also lower memory usage and there is no DepNodeIndex fragmentation, but it also does more work than an append only approach --- ### Minutes Design Meeting 2019 11 09 Unified Dataflow Framework (`content/minutes/design-meeting/2019-11-09-unified-dataflow-framework.md`) --- title: Unify Dataflow Frameworks (#202) type: docs --- # Design Meeting 2019-11-08 [Zulip Stream](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-08) # Agenda - Design doc: https://hackmd.io/@39Qr_z9cQhasi25sGjmFnA/Skvd9rztS - Explain the current state of things - We currently have two wholly separate APIs for dataflow, one for bit-vector problems and one that allows arbitrary transfer functions but still restricts the lattice to a powerset of indices. - I want to merge these two to make code more DRY. - The prototype implementation is described pretty thoroughly in the design doc, but maybe go over it a bit? - Discuss the [prototype implementation][proto] in general - The prototype is not very ambitious. It mostly preserves the existing `BitDenotation` API but extends it to arbitrary transfer functions. - Do we want to maintain the status quo? Have two separate implementations forever? Once arbitrary lattices are supported, maybe they won’t fit as nicely into the same API. - OTOH, adding backwards analysis would have to be done in two places. - There have been more ambitious changes attempted. Perhaps we want to do one of these instead? Or at least incorporate some of their ideas into a framework that hews closer to the existing one. - nagisa worked on a [new dataflow framework][nagisa] that works for arbitrary lattices and transfer functions back in 2016. - eddyb was looking into a simultaneous forwards/backwards [dataflow-like thing][eddyb] for NRVO. - Discuss the prototype in detail (If we decide we still want to go this way) - How do we feel about the `{before_,}*_effect` naming convention? It takes a bit of getting used to, and doesn’t extend nicely to backwards dataflow. - OTOH, having a canonical `statement_effect` which most implementers want to use and a secondary, prefixed effect which is only rarely used is good. - Should we be passing a `mir::Statement` to the `statement` effect methods? What about `mir::Body` to `bits_per_block`? - Should we use specialization to implement this?’ - Should the `Analysis` methods take `&self` or `&mut self`? - Some may depend on the results of an earlier dataflow analysis and want to hold a cursor. - However, transfer functions should be pure for a given MIR, so maybe forcing those analyses to use interior mutability is appropriate. - Are we okay with a `ResultsCursor` becoming the common way to inspect results? - How do we implement a zipped `ResultsVisitor`? - Discuss what extensions to the framework we want to prioritize - Backwards dataflow (currently implemented by hand to do check liveness in generators) - Arbitrary lattices (would make MIR const-propagation more powerful) - OTOH, the current linear const-propagation gets most of the benefits without the overhead of dataflow. - Optimizations: - Don’t cache block transfer functions on acyclic MIR (reduces memory usage) - Extended basic blocks? @Mark-Simulacrum # Minutes - Background on the need for arbitrary transfer functions for dataflow and const qualification. - Alternatives to the prototype: - Perhaps we could express these more advanced dataflow problems in datalog/datafrog? - nikomatsakis wanted to test more in the polonius repo before committing to this upstream. - The need for `apply_call_return_effect`: - We need some version of this, but not necessarily the current version. - API details - Skipped most of these, since they can be figured out later. - mir_borrowck might benefit from `ResultsCursor` now that it is implemented. - Optimizations/extensions - Some interest in not caching block transfer functions for acyclic MIR. - This is pretty easy, I will prioritize this. - Probably not going to do EBBs anytime soon. # Conclusions - There was consensus on pursuing some version of the prototype instead of something more radical. - Details will be hashed out in a PR to come. - @ecstaticmorse will pursue this. [proto]: https://github.com/rust-lang/rust/pull/65672 [nagisa]: https://github.com/rust-lang/rust/pull/35608 [eddyb]: https://github.com/rust-lang/rust/pull/47954 --- ### Minutes Design Meeting 2019 11 16 Working Group Retrospective (`content/minutes/design-meeting/2019-11-16-Working-Group-Retrospective.md`) --- title: Working Group Retrospective type: docs --- # Working Group Retrospective * [Zulip stream] or read on the [Zulip archive](https://zulip-archive.rust-lang.org/131828tcompiler/82575designmeeting20191112.html) [Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-12 ## What you are looking at We did a [short survey](https://forms.gle/PmZVgsAWZckceT3Y6) before the meeting. The following notes were scraped from the 10 responses. I tried to de-duplicate common items. Towards the end, you will find some minutes that were taken during the meeting itself. --nikomatsakis ## Things to KEEP doing * Working groups are useful * Nice to know who to talk to in order to get involved * this was more of a struggle before * Providing opportunities for mentorship is good * Scoping out small groups of decision makers for "in the weeds" decisions * Weekly updates * Dedicated Zulip streams: great to have ability to link/skim, even if most are muted * Regular meetings are a good way to keep working groups focused ## Things to STOP doing * Maybe fewer working groups, with more time/energy invested in each? * Some of the smaller WGs don't see much activity, could discourage people ## Things to START * Check in with WGs not just about achievements but process * e.g., diagnostics and mir-opt don't have any meetings * Question from editor: Not clear if the idea here is to try and have a more uniform process across teao use that as a signal that help may be needed * yes, that's what I meant * which is what you meant? :) * Improve our labeling system * Tag PRs with WG-XXX instead? > [name=Centril] Instead or both? We (T-release) can still use A-* labels. > [name=Felix S Klock II] I worry about *switching* to this (rather than the A-categories) because it can mean that multiple WG's get pings for incidental stuff...? I guess the labels don't actually cause pings so maybe that doesn't matter. Another potential issue (again that arises from multiple WG-labels on one issue) is that it can become ambiguous *which* WG should be taking lead on something. * Proactive recruitment for specific working groups? * Devise metrics to evaluate effectiveness? * [name=Centril] What would those metrics be (also... performance reviews? ^^ Rust is not a company; heh) * Should WGs create those? * Figure out the "wind down" process (e.g., for groups like NLL and pipelined compilation) * Do we need to document which members are responsible for long-term maintenance? * Consider e.g. NLL * How to ensure the remaining work gets done? A lot of it is falling to Matthew Jasper for NLL, is that ok? * Some better way to advertise what we are doing ## Things to IMPROVE * Longer timeslot in compiler team triage meeting (maybe just a few minutes) * More time for discussion or Q&A related to plans, progress, etc > [name=Felix S Klock II] maybe if we just moved it to the begining but had a hard limit on time? * Onboarding could still be improved * Some better way to get a sense of status without participation in every compiler team meeting * Maybe use Inside Rust blog or other means to make more regular public announcements * Maybe a regular (but less frequent) time when *all* groups can check-in * Require explicitly documented leaders, some older WGs are missing them * Improve use of WG labels: * the set of github WG labels and actual WGs do not correspond in a meaningful fashion * Hard to know when to use the A label vs WG - [name=Centril] This is primarily a matter for T-release triage. When in doubt, use both labels. * Distinction between shorter and longer term groups * maybe use distinct terms * add metadata indicating this * Help ensure that each working group has active leadership, which makes a big difference * hard to find people with enough time * maybe we can help leaders? * multiple leads are good * [name=mw] +1! [name=Centril] +1 * More involvement from the lang team on Zulip is useful, developing a better working relationship between lang and compiler team would be good * [name=Centril] The lang team recently "moved" to Zulip * [name=Centril] Narrowing the funnel through which T-lang adds new work to T-compiler's queue would be good * Relationship between triaging wg (from release team) and compiler team * * More retrospectives to help us reflect on how things are going! * compiler-team web pages feel like they could be better * templates are not that useful * would be nice to have the updates there * overhead of maintaining all the web pages and other things feels too high * can we post updates in a more central fashion? * fold the activity of "regular contributors" into the working groups more ## Other things * don't generalize too much from NLL, it was a big prominent lang feature with lots of interest ## notes and ideas from meeting The following notes and conclusions were extracted during the meeting. For more details, please see the complete [Zulip stream]. ### discussing check-in and how to keep the info up to date * maybe a zulip stream that people can post updates to * perhaps with bot support to scrape and collate * this would land in github in the form of meeting minutes * but it would also make it easy to catch up on the status * make a point to help WGs develop roadmaps * helps to frame check-ins * metrics? * but what? and let's not try to make this too much like a company * wind-down * things like NLL are winding down but it doesn't feel very organized * even the concept of wind-down requires more work on roadmaps, so this ties in with the point above * maybe the next step for winding down is to try and use that process, but aimed more at finding the work left to be done * goal: "what did we get done, what's left, and -- if it matters -- who will do it" * kinds of working groups * groups doing manual, recurring tasks and upkeep * groups around an area of the code ("WG-NLL", "WG-mir-opt") * project groups with a pretty clear goal ("WG-NLL") * maybe projects are things that "area-based groups" do? * groups to ping people ("ICE-breakers", "WG-rollups") * labels * some way to indicate that the issue has been triaged by a given wg (e.g., `AsyncAwait-Triaged`) * follow-up topics to drill into more * creation of wgs is undocumented * there are ongoing activities that it would be great to "capture" in a WG * designation of kinds of working groups didn't reach much of a conclusion --- ### Minutes Design Meeting 2019 11 29 Repl Meeting (`content/minutes/design-meeting/2019-11-29-repl-meeting.md`) --- title: Read-Eval-Print-Loop (REPL) Extensions type: docs --- * [Zulip stream][] or read on the [Zulip archive][]. [Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-29/near/182183477 [Zulip archive]: https://zulip-archive.rust-lang.org/131828tcompiler/72407designmeeting20191129.html # Agenda - Design doc: https://hackmd.io/GJokfI0wQ0i4SIgRbFTmfw - Big picture overview and questions - Essential changes to support REPL extensions # Big picture overview of design, and on-the-fly questions about it - Read (to an AST), Compile (AST to MIR), Eval (the MIR to a value), Print (the value). and Loop. - Question: Is this going to be a tool analogous to miri, where check-in's that break it may not break CI immediately, but rather will just file follow-up bugs? - Answer 1: it has to be a tool; it depends on miri (or a fork of miri) - Answer 2: it will be even less than a submodule (where a CI automatically files follow-up bugs): There won't be any automatic filing of follow-up bugs (alexreg has said they will handle maintenance manually); this is how miri and clippy had initially started. It could become a submodule later. - Question: Does this mean if we (rustc developers) make breaking changes to the compiler, we won't necessarily know, right? (Unless explicit tests are added to rustc test suite.) - Answer 1: Yes, but this is considered acceptable - Answer 2: We can annotate relevant points in `rustc` with `// REPL` comments, (e.g. to avoid them being made private or removed due to lack of use in rustc). - Design doc is split into (interleaved) essential and non-essential changes - For remainder of meeting, we reviewed each essential change at a high level, and asked participatnts about their thoughts on that change. # Add an “interpreter mode” to the compiler interface - E.g. conditionally prevents dead user variable elimination. - for example, when you do `let x = ...` in the repl, you want `x` to be kept around for the future repl inputs. - Question: Are there other contexts where one would the dead-user-variable-elim optimization disable? - Answer 1: Probably not - Answer 2: Patching a running binary, perhaps - Question: What deos it mean to prepend local variables from previous evaluation sessions? - Answer: For each live variable add `#[rustc_repl_alive] let var: type;` - Conclusion: No one objects to the addition of the "interpreter mode" flag # Slightly expanded miri API - "Added insert_alloc method to machine, used by REPL for restoring memory when deserialising previous evaluation session." - There was some debate about exactly where this would need to go, but everyone agreed that the functionality was necessary. - "Added hooks before_statement, after_statement, before_stack_push (renamed existing method), after_stack_push, before_stack_pop, after_stack_pop (renamed existing method)." - no objections to these additions - "Made stack pop behaviour more flexible, so as to allow the cleanup flag to be independent of wherever the action is null or a “goto”." - Question: What are the stack pop changes? - Answer: it's important that we can exit a block / pop off the stack but still not perform cleanup (so as to be able to serialise the values of the locals when execution is done). - Question: Is the cleanup the running of destructors? - Answer: more like clearing the local's memory - no objections to this addition # Any remainning conerns from stake holders? We reviewed some vague misgivings with certain design decisions, but no one had strong objections. Its not typical to accept changes like this for supporting other projects, but it is also not unheard of (e.g. miri, priroda, clippy). Conclusion: people are generally okay with moving forward with what alexreg laid out, at least the Essential portion --- ### Minutes Design Meeting 2019 12 06 End To End Query PRs (`content/minutes/design-meeting/2019-12-06-end-to-end-query-PRs.md`) --- title: 2019-12-06 end-to-end query PRs type: docs --- # Design Meeting 2019-12-06 -- librustc_interface queries ## Links * [Zulip topic of the discussion](https://zulip-archive.rust-lang.org/131828tcompiler/75795designmeeting20191206.html) * [Compiler team issue](https://github.com/rust-lang/compiler-team/issues/175) * [Pre-design meeting Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/pre-design.20meeting.202019-12-05) * [Internals thread](https://internals.rust-lang.org/t/migrating-rustc-interface-queries-to-proper-librustc-queries/10433) with descriptions of PRs ## Background * Goal is **end-to-end queries** * Benefits: Simpler overall model * Incremental extending back to parsing * mw has done measurements suggesting that on larger crates some 40% of the compilation time comes from * Parallel compilation would be more effective, if done on the basis of queries * Agenda * Tough to frame:) * Most important question to settle is what overall stategy we plan to take * Do we want to try and land / rebase these PRs? * Try a different tack? * Hold off and let other things progess? ## Commentary on the meeting This is written after the fact, and is an attempt by nikomatsakis to capture some of the key considerations. * The PRs were written with the goal of moving rust immediately to an end-to-end query system * the queries that get created here are not, however, as clean as one might expect * as an example, instead of creating fine-grained queries for handling HIR, we would create a single HIR Map query and retain today's special case code that tries to track which bits of the data the methods on the HIR map access * An alternative approach would be to move more slowly but work more on the actual design of each piece * We might start with the HIR, decide on the actual representation that we want, and refactor into that * And then move backwards to name resolution * This overlaps somewhat with rust-analyzer, which has been built "from the ground up" with queries in mind, and thus has been figuring out some of what is needed here * For context, there are definitely benefits from changing the line around the "set of things captured in the query system" * e.g. big parts of the webrender-check compilation takes place before incremental even starts * The concerns with the PRs are that * we are kind of creating more tech debt before we start to pay it off * since the designs are not the designs that we ultimately want * there isn't really a precise enough consensus around the end state that we want * and thus trying to move incrementally means we are kind of ambling without a clear goal * and likely to wind up with something incoherent * the PRs introduce more special cases into the query system, not fewer * On the other hand * moving quickly to create queries might unlock other improvements, help us eliminate shared state * maybe you see this as an "obvious first step whatever we do", in which case there isn't a lot of room to block * counterargument is that these PRs are each quite complex and take a lot of reviewing load to manage etc * We discussed a fair amount what a desirable design for HIR might look like, [starting around here](https://zulip-archive.rust-lang.org/131828tcompiler/75795designmeeting20191206.html#182771577) * it seemed like there was general consensus around a "vague sketch" where you had `tcx.hir(def_id)` give you back some kind of `ItemData` that contained the data for a particular item * no 'special cases' needed in the query system * [Alternative proposal](https://zulip-archive.rust-lang.org/131828tcompiler/75795designmeeting20191206.html#182772402) * close the PRs * encourage creation of a WG to work out a design for HIR, HIR-ID and the like and bring that design forward * land new PRs working in that direction * this overlaps heavily with rust-analyzer and could even take place in that context * Towards the end, some topics were raised that were not fleshed out * such as whether a `DefId` could be a "interned" DefPath (or whether it already is) * the need for 'queries that depend on queries' and what that means --- ### Minutes Design Meeting 2019 12 20 Major Change Process (`content/minutes/design-meeting/2019-12-20-major-change-process.md`) --- title: 2019-12-20 major changes process type: docs --- # Major Change Process * [Zulip thread](https://zulip-archive.rust-lang.org/131828tcompiler/44719designmeeting20191220.html) ## Summary * We want some kind of system where people advertise changes that they are making or plan to make * and the team can give high-level feedback early * and -- if we decide to go with the change -- we can ensure there is a reviewer beforehand * This document describes motivations and a specific "early draft" proposal ## Motivations Proposal is to add *some* sort of notification / lightweight process before making major changes. In contrast, today there is no stated process for a "major change" beyond just opening a PR. Of course some changes get a lot of discussion before hand, but others do not. Some problems that we see with today's system: * Sometimes we get large PRs that have attempted a major change without any discussion beforehand * There may not be a reviewer with time and interest * Also reviewing without context is very difficult * There may be concerns about the technical approach or direction * Starts the discussion with "accept or reject this PR" versus "what is best approach" * On the other hand, a more concrete discussion can be more effective * Often, as a result, these PRs can sit for a very long time without any feedback * this is frustrating for everyone involved * Current "lack of system" can also be a turnoff * do a lot of work to prep PR, but can you know if that change is welcome? * Over time, a focus on PRs (versus explaining the idea) leads to * more tech debt and less overall cohesion * lack of documentation Some strengths of today's system that we would like to preserve: * Low barrier to entry, not a lot of "bureaucratic overhead" * People should be able to experiment without "authorization" before hand * We don't want a lot of overhead for the *compiler team* to manage some authorization process We would know the system is working if: * We have a better idea of what is being done and by whom * and also whether the team has approved of that direction * Major changes will be discussed before they become a PR that is up for active review * reviewers will be identified beforehand * When reviewing a PR, reviewers will have a better idea of its goals and how it fits into the bigger picture * We still have a "high throughput" system and we don't spend a ton of time on "bureaucratic overhead" * in particular we should be able to "green light" changes fairly quickly and we should do that most of the time ## Initially proposed process * When considering or experimenting with a "major change", open an issue on compiler-team repo to let people know * Describe the general idea in a sentence or two * Identify mentors or reviewers, if you are working with one * These issues will be reviewed weekly and classified * New triage process? Part of existing process? > [name=Felix S Klock II] Note we already often go-over allotted time at the Thursday triage meeting. We *can* add this to the agenda, but we need to figure out what else will get de-prioritized. * Is weekly a good frequency? * mark: this is pretty high latency for some of these changes, we might otherwise merge them in a week's time Maybe that's not a bad thing though :) * Some possible outcomes: * Closed -- this doesn't seem like something we want to do * Requires design meeting -- requires a larger group > [name=Felix S Klock II] should also add "Needs RFC" as potential outcome (a more extreme variant on "Needs Design Mtg") * Deferred -- not deciding for now, or trying to find a reviewer * Approved for experimentation * once PR is ready, nominate for discussion * may request "mitigation", such as a `-Z` flag * implementor should understand that we may just decide the idea isn't worth it * Approved to land -- requires a willing reviewer * no special approval required to land, just r+ * If a "major change" PR is opened without going through this process * Close with a friendly note recommending an issue be opened (we should write a standard template with a link) ## What is a "major change"? * "You know it when you see it" * If it is a major time commitment to review it, it probably qualifies * This might be beause it affects many parts of the compiler * But it might also be a narrow change with subtle implications * Or require reading up on a relevant RFC or other background material * Examples of major changes: * Allocate HIR on an arena: * Yes, because it touches a set of data structures used throughout the whole compiler * However, presuming we could find a reviewer, this would be something we'd like approve quickly within the initial triage because it is fairly mechanical and doesn't require a design meeting * Introducing chalk, nll, or polonius * Yes, replacing a major component * This kind of effort might be "redirected" to forming a working group to help lead the design and implementation * (which is of course what we have done) * Changing universally used internal APIs * Heads up, `PlaceBase::Static` is being removed, breaking every single use site of place.base: https://github.com/rust-lang/rust/pull/67000 * Grey zone, let's discuss: * Const propagation * It is major in that it is something that has been discussed quite a bit, multiple people might have ideas on it * It is low-risk because it can easily be turned off at any time * [Use the recorded types in MIR to determine generator auto-trait implementations](https://github.com/rust-lang/rust/issues/65782) * [Implement RFC 2532 – Associated Type Defaults](https://github.com/rust-lang/rust/pull/61812) * contained, but reviewing is a lot of work * Niko has rather inexcusably let this sit far too long (plans to change that) * *But* it's an example of something that's hard to schedule, and where some up-front notice might've been helpful (or could've given warning that won't have available bandwidth until later) * Examples of minor changes: * Fix some ICE * Local optimizations ## Why this will help * For people who have very full calendars, being able to have a "heads up" of larger changes and to integrate into a review schedule could be helpful * but it will take discipline to use effectively ## Notes from the meeting * simulacrum points out that it would be good to have some kind of "fast path" if you have a reviewer and you have documented things, so that no meeting is required at all * the only "hard block" would be if you don't have a "partner" or "sponsor" from compiler team * somewhat analogous to the project group lang team concepts * reviewer not expected to be a pair programmer * one possible definition for "what is a major change" might be "what would modify the rustc-dev-guide" * or, since rustc-dev-guide is always a WIP, "welp this *should've* in the guide and if it were, it *would've* required a modification" * what to do with new PRs that don't follow the process? * should we close them? * maybe have a canned comment and give them some amount of time * this comment might also emphasize the role of documentation * [we discussed and settled on](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-12-20/near/183945490) * leave a nice message, which it S-waiting-on-author * close per usual triage process if no issue is filed within a certain amount of time * if an issue is filed but it is not "green lighted", then we can close the PR * i.e., if we decide that a design meeting or broader project group is needed * when a project is proposed, what are the possible responses? * I have concerns * I approve but don't have ability/time to review * I approve on an experimental basis; we should discuss again when we gain more experience * I am happy to review but I would like another to approve too * I am happy to review and I think we can just go forward (only possible for "members") * can we make a Zulip stream where each issue creates a topic? * how to handle experimentation? * we should have some way to add "caveats", like * would like to review performance results * we need a `-Z` flag * we need docs :) * final discussion point was about exactly how to handle requests for rustc-dev-guide edits * since a major change is part of a rustc-dev-guide change, it makes sense that it should come accompanied with a rustc-dev-guide write-up * ideally this would come along with the compiler-team issue * but maybe it would be more something we wait for until issue is *approved* or, in extreme cases, co-develop with author * if we want to see more docs, we are going to have to start holding the line *somewhere* * sometimes it's not possible or desirable to write complete docs before-hand * details may change through review process * person may not know enough context to write the docs, need help with that * but the bar should be that the issue can **explain the change** in sufficient detail for it to be understood * the *actual* rustc-dev-guide changes themselves can come later * it may be that the role of the rustc-dev-guide wg can be to help with some of that ## Final proposed process * When considering or experimenting with a "major change", open an issue on compiler-team repo to let people know * Describe the general idea in a sentence or two * Identify mentors or reviewers, if you are working with one * There will be some "prototype" to guide people in this * What is a "major change"? * something where it would make sense to update rustc-dev-guide * if rustc-dev-guide doesn't cover this code yet, then you may have to use your imagination about what *ought* to be documented :) * These issues will be reviewed by compiler team members * Compiler team members and contributors can leave concerns and approvals asynchronously (see below) * maybe we can make a dedicated Zulip stream where new things get * In particular, note that a compiler team member who is confident something is correct and will not be controversial can just go ahead and approve and act as reviewer * though there should still be an issue * But there should also be some synchronous sweep, not clear when that should occur * maybe as part of meta wg? * perhaps just team co-leads do it on a regular basis? * existing triage meeting is too full, that's clear * Feedback from a compiler team member or contributor typically has the form (these are not fully orthogonal): * I have concerns (give details) * this might lead to more details * or a design meeting * or an RFC * or just closing the idea * I approve but don't have ability/time to review * I approve but with some caveats, e.g. we should examine perf afterwards, would like to re-review, or want a `-Z` flag * I am happy to review but I would like someone else to approve too (must be a "compiler team contributor") * I am happy to review and I think we can just go forward (only possible for "members") * the idea here is that if you are an expert on the code and confident this is a good path, that's fine, do it * If a "major change" PR is opened without going through this process * We post a standard comment that directs people to open an issue * And the PR is marked as waiting on author * It can be closed per the usual triage process if author does not respond * If the issue turns out to be controversial (i.e., nobody steps up as reviewer write away), then we close the PR and just focus on discussing in the issue ## A few more last minute notes * Centril + nikomatsakis discussed a bit after and noted that we probably don't need to get formal about members vs contributors, the key point is that if somebody is confident that (a) they know this is the right approach and (b) they know others will agree, they should feel free to move a major change forward (and leave notes to that effect on the issue) --- ### Minutes Design Meeting 2020 02 28 Focused And Efficient Triage (`content/minutes/design-meeting/2020-02-28-focused-and-efficient-triage.md`) --- title: 2020-02-28 focused and efficient triage type: docs --- # Focused and Efficient Triage - [Meeting proposal](https://github.com/rust-lang/compiler-team/issues/247) - [Pre-meeting notes](https://hackmd.io/5theN85oRS6QvyYPZt-vew) - [Zulip meeting thread](https://zulip-archive.rust-lang.org/131828tcompiler/36846designmeeting20200228.html) The goal of the meeting was to discuss the idea of creating a **pre-triage working group**, the tasks we need to do and who should be doing them. The motivation is that (a) a lot of work for our current triage process is falling on @pnkfelix and (b) there is a kind of lack of clarity around our goals, how we use our labels, etc. ## Things we need to do - Monitor and identify "critical bugs" that are not making progress - For critical bugs not making progress, find someone to fix - Making general quality improvements and enhancements (i.e., "fixing non-critical bugs") - Ensuring deferred things are picked up again (e.g., future compatibility warnings) - Processing new issues, ensuring labels are up to date, identifying bugs that are out of date or have been fixed ## Typical flow for an issue * Issue gets filed * Release team applies labels * area labels, team labels * If bisection, mcve needed: * tag with needs-bisection, needs-mcve * cc "Cleanup crew" * In some cases: * directly prioritize or send to the right place if it seems clear * otherwise, nominate for compiler team meeting * Release team nominates for compiler team to further process * also cc folks to bisect * (usually ICE), usually includes needs-bisection and needs-mcve * Compiler team triage group analyzes and figures out which things apply * Critical bugs: * Tag with P-critical * Needs team discussion: * Delegation: * Should we cc ## Proposal - We should have two distinct triage groups compiler and release - T-release/triage does try to "classify" bugs before it goes to t-compiler - T-compiler/triage wg should be deciding if bugs are critical (potential release blocker) or not - We would need to tag critical bugs P-critical - That's a key area of focus - Those are potential release blockers ## T-compiler/triage WG scope - Process I-nominated issues and process those into categories, critical, needs team discussion, delegate) - The main focus should be to identify new P-critical bugs. - Revisit the set of all P-critical bugs to double check that they have logged progress. - Prepare key highlights to guide the main weekly meeting ## Charter for T-compiler/triage WG * Processing 'nominations' and routing bugs to folks who can fix them * Identifying *critical* bugs and monitoring them to ensure they are making progress * Identifying the agenda for compiler team triage meetings * Critical issues that are not making progress * Issues where bugs are nominated for needing wider discussion * Ideally, crystallize * Tracking deferred things and ensuring they are picked up again * Future compatibility warnings --- ### Minutes Design Meeting 2020 03 12 Shared Library For Types (`content/minutes/design-meeting/2020-03-12-shared-library-for-types.md`) --- title: 2020-03-12 shared library to represent Rust types type: docs --- # Shared library to represent Rust types ## Notes from the meeting The later sections of this document were largely prepared before the discussion. This section contains notes from the discussion itself. You can [also read the complete discussion in our zulip-archive](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html). ### Conclusions * [consensus from folks in the meeting:](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189906358) * are "cautiously optimistic" about this approach, and open to us trying to create PRs that move rustc in this direction * are ok with having a rusc-ty library that is published to crates.io * but there remains disagreement about the big picture question of how stable API boundaries can/should be between libraries, whether they should live in their own repos, and whether they should use unstable features (but that was not the direct topic of this meeting, so that's ok) * [sketch of a plan for how to do the transition](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189906441): 1. ty.kind -> ty.kind() 2. ty.kind() -> ty.kind(tcx) 3. Add a type alias and make kind work on I: Interner 4. Start using Ty more (This is a lot of PRs) ### Key or interesting points Some key or unique points that were raised during the discussion: * [abstracting more over the concrete representation of types permits experimentation for performance reasons](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189902761) * impact of more generics: * [more generics may increase compilation time](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189902837), although [this is not clear](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189902975), and we also get the [advantage that we can write libraries that do not depend on most of rustc](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189903076). They would use traits like the proposed `Intrner` trait or chalk's `RustIrDatabase` trait to isolate out their dependencies. * [we won't be able to use pattern matching](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189902911) * generics also permit [logically separating out different sets of types](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189903514) in your code (e.g., inputs and outputs), even if they both ultimately share the same representation * interactions with MIR * [types include constants](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905039), which reference MIR, is that a problem? * no, [because types reference MIR through def-ids](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905156) * rustc-ty feels like a dependency that could be used to build a rustc-mir that just defines MIR (but independently from rustc) * to do the transition: * [two main parts](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904385) that are somewhat independent: * reshape `TyKind` to a more chalk-like hierarchy * introduce the interner, which can be done via a series of PRs like [`ty.kind -> ty.kind() -> ty.kind(tcx)`](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904318), and as described in the proposal below * one question was whether we [should we do more of the experimentation in rust-analyzer or chalk first](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904326); but doing the work on rustc means we will [encounter the interesting side-cases](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904326). Still, we have done the work on chalk already and [should start migrating rust-anayzer to share representation with chalk, too](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904518) ### Deferred questions Some bikeshed or other detailed questions were raised but largely deferred: * rustc today uses `ty.kind` to get the "kind" of type, chalk uses `ty.data()` -- which name is preferred? * [we may want to support flags also on "lists of types"](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189903142) * what to [name the crate](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904735) * should the library [use unstable features](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189904914) and [how stable should it be](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905312)? * this was largely deferred but we did get into some of the interesting details, particularly on the question of stability * being more stable (even just noting when there are semver-relevant changes) requires us to take on some more overhead * maintaing version numbers, maybe a [changelog](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905621) * avoiding nightly means we can't dogfood features, some of which don't see that much usage in the ecosystem * but: * it would be great it [rustc development](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905824) felt much like working on any other rust project, e.g. using cargo + stable * and having libraries that people can build on would eventually enable [more complex tooling like Roslyn](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905590); people want this, think Mirai * if we can find meaningful boundaries between crates, [maintaing semver shouldn't be so hard](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905511) ([but can we?](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905601)) * ultimately we [deferred the question](https://zulip-archive.rust-lang.org/131828tcompiler/05771designmeeting20200306.html#189905940) to discuss more explicitly and with more experience ## Context As part of library-ification, we need a library to represent Rust types. The intent is that this library can be used by chalk, rustc, rust-analyzer, and any other projects which need to represent Rust types. Goals: * Do not hard-code the use of interning. Interning is a good fit for batch compilation but not such a good fit for IDEs, which need to be able to gradually release memory on an ongoing basis. * Ergonomic library that is pleasant to work with. * Simplify Rust's types to "their essence", while retaining full information ## Goals for this meeting * Discuss the "high-level plan" for the design * Discuss the roadmap and initial steps to work towards this goal ## Non-goals * We do not need to decide the fine details of the type (e.g., what variants there are, what to name the methods, etc) at this time. We will work those out through PRs and refactorings. * Figure out the mono-repo vs poly-repo question and where the shared crate should ultimately live (I sketch some interim solutions below) ## Proposed end-goal: crate structure This idea is part of a broader 'library-ification' effort. The goal is to build up independent crates for the various parts of rustc, like the trait system, type checker, name resolution, etc, that can be shared by both rustc and rust-analyzer. This particular meeting is talking about what might be part of a crate that describes Rust types, which we'll just call `ty` for now. This crate would be the foundation for a lot of other crates: ``` "rust-analyzer" ^ | ty --> "trait system" -----+---+--> "rustc" | ^ | | | | +---> "type checker" -----+ ``` In other words, we are talking about ultimately replacing [the `Ty<'tcx>` type that rustc uses today](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) with a type defined in this `ty` crate, modeled roughly after chalk's [`Ty`] type. ## Proposed end-goal: the basic pattern for representing types The proposed design is described in some detail [in the chalk book](http://rust-lang.github.io/chalk/book/types.html), so you may wish to read there. However, I do want to emphasize that the *fine details* (e.g., exactly which variants we should have) should not be considered normative. [`Ty`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html In the proposed design, Rust types will ultimately be represented by a struct that looks like this, based on [`chalk_ir::Ty`][`Ty`]: ```rust pub struct Ty { interned: I::InternedType } impl Ty { ... } ``` Clearly, `Ty` itself says very little. It is just a "shell" that wraps around the interned representation, which is defined via the `Interner` trait: ```rust trait Interner { type InternedType; fn intern_ty(&self, data: TyData, flags: TyFlags) -> Self::InternedType; fn lookup_ty_data<'ty>(&self, ty: &'ty Self::InternedType) -> &'ty TyData; fn lookup_ty_flags<'ty>(&self, ty: &'ty Self::InternedType) -> TyFlags; } ``` To actually *use* a type, you wish to invoke the `data()` method (you have to supply a reference to the interner): ```rust impl Ty { pub fn data(&self, interner: &I) -> &TyData { interner.lookup_ty_data(&self.interned) } pub fn flags(&self, interner: &I) -> &TyFlags { interner.lookup_ty_flags(&self.interned) } } ``` This method returns a reference to a [`TyData`], which is the actual `enum` that defines the type variants. The definition that follows is taken from Chalk: [`TyData`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyData.html ```rust enum TyData { Apply(ApplicationTy), Placeholder(PlaceholderIndex), Dyn(DynTy), Alias(AliasTy), Function(Fn), BoundVar(usize), InferenceVar(InferenceVar), } ``` As noted before, don't focus too closely on the precise set of variants. Chalk aimed for a very minimal set, and the idea was to [justify each variant](http://rust-lang.github.io/chalk/book/types/rust_types.html#justification-for-each-variant) by explaining clearly why some bit of code might want to look for types of that variant, but I expect that we'll ultimately want to find some "sweet spot" in between rustc's approach (lots of variants) and chalk's approach (minimal set). **The key thing to discuss here:** * A `Ty` type with an `I: Interner` parameter that defines its representation ## Interner in Rustc The interner in Rustc would be `TyCtxt<'tcx>`, and hence we'd have something like ```rust impl<'tcx> Interner for TyCtxt<'tcx> { type InternedType = &'tcx TyData; fn intern_ty(&self, data: TyData) -> &'tcx TyData { self.interners.allocate(data) } } ``` ## How to get there from here Presently, rustc, chalk, and rust-analyzer each have their own type definitions. The goal is eventually that all three projects should share the same crate that defines the type definitions, using the above generic style. But how do we get to that goal? And where should that crate live? This ultimately plays into the mono- vs poly-repo discussion and I would rather not go there in this meeting. It seems like we can address the questions a bit later when we have made more progress. Until then, I propose that we gradually refactor rustc so that the types in rustc approach the goal described above and ultimately factor out a `rustc-ty` crate that contains just the type definitions (and some supporting types). This should be a crate that can be published on crates.io (as well as living in tree). chalk can then depend on this crate. Once that is done, we could consider whether the crate should move to chalk (which would be moving towards polyrepo) or whether it should remain in tree, or whether we adopt some other, hybrid solution ([as discussed here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/toolstate.20breakage)). In more detail: * Rework the `TyS` API so that you access the variants by `ty.data(tcx)` and not `ty.kind` (similarly flags) * Introduce an `Interner` trait into rustc and refactor from `type Ty<'tcx> = &'tcx TyS<'tcx>` to `type Ty<'tcx> = ty::Ty>'` * Extract the type stuff into a `rustc-ty` crate * this should have no dependencies on other parts of rustc and be something we can publish to crates.io * Make chalk depend on that crate ### chalk integration Note that while the above work is proceeding, we may **also** want to experiment with "chalk integration". This would be done by having `-Zchalk` cause rustc to translate its types (however they may be represented) into the minimal chalk-ir types on demand. As rustc's types come to match chalk-ir types (and/or chalk-ir types change to match rustc types), this would be a simpler and simpler translation and would eventually become a no-op once rustc + chalk share the same type definitions. ## Where should this crate live? This crate will start to re-raise the question of poly- vs mon-repo. I would like to dodge that particular discussion for now. What I've proposed above has a `rustc-ty` crate living in tree. This is obviously the right place to start, but ultimately I think we should consider the idea of having "type related code" living in a separate rust-lang repo (like rust-lang/chalk), which might ultimately include the representation of types, the trait solving code, and perhaps the type checker (and depend on some other repo which provides the HIR that gets type-checked). But obviously this would carry coordination costs and all of this seems far enough way I'd rather not discuss it in this meeting. --- ### Minutes Design Meeting 2020 04 03 Cranelift Backend For Rustc (`content/minutes/design-meeting/2020-04-03-cranelift-backend-for-rustc.md`) --- title: 2020-04-03 Cranelift backend for rustc type: docs --- # Cranelift backend for rustc You can also read the [complete discussion in our zulip-archive](https://zulip-archive.rust-lang.org/131828tcompiler/01241designmeeting20200403compilerteam257.html). [Meeting Proposal](https://github.com/rust-lang/compiler-team/issues/257) [Pre-meeting details and agenda outline](https://hackmd.io/@bjorn3/HJL5ryFS8) ## Overview of the Cranelift backend [Cranelift](https://github.com/bytecodealliance/wasmtime/tree/master/cranelift) is a code generation backend written in Rust which is under development for use in WebAssembly compilers. As such, it could potentially improve compilation times in `rustc` because it is optimized for efficiently generating code rather than generating efficient code. Over the past ~1.5 years, [@bjorn3](https://github.com/bjorn3) has been working on writing a Cranelift-based code generation backend for `rustc`: [`rustc_codegen_cranelift`](https://github.com/bjorn3/rustc_codegen_cranelift) or `cg_cranelift` for short. It is currently complete enough to compile many programs and is usually faster at compiling them than the regular LLVM backend. The main goal of this project is to build an alternative codegen backend that can be used for faster, non-optimized (debug) builds. `rustc` has support for runtime-pluggable backends via the unstable `-Zcodegen-backend=/path/to/dylib` flag. `cg_cranelift` is developed in a separate repository from the Rust project, so it uses this flag to plug into `rustc`. `cg_cranelift` also takes advantage of an internal `rustc` library called `rustc_codegen_ssa` which tries to be a backend-agnostic code generation support library but some parts of it are still very LLVM-like. ## Next steps At this time, we want to help increase the support `cg_cranelift` gets but it isn't a top priority for us currently. The eventual goal seems to be first-class support for `cg_cranelift` alongside our existing LLVM backend but that won't happen for a while so we can afford to take small, measured steps in the meantime. A few things we would like to do now: - Continue refactoring `rustc_codegen_ssa` to be less LLVM-like and allow `cg_cranelift` to re-use more of the code. - Bring in `cg_cranelift` to the `rust` repo (probably via `git-subtree`) and require it to build during CI. - This is similar to the support we give to tools like clippy or miri. - Add a way in our testing infrastructure to mark tests as reliant on a specific codegen backend and annotate existing tests that require LLVM. - Add a way to manually run tests with `cg_cranelift` to Rustbuild (aka `x.py`). We may also want to do these soon but we need additional discussion: - Run tests in `cg_cranelift` mode and notify if they failed (but don't gate CI on it). - Form a working group related to `cg_cranelift`. --- ### Minutes Design Meeting 2020 05 29 Roadmap 2020 2021 (`content/minutes/design-meeting/2020-05-29-Roadmap-2020-2021.md`) --- title: 2020-05-29 Roadmap 2020-2021 type: docs --- # Links * [Zulip topic](https://zulip-archive.rust-lang.org/238009tcompilermeetings/94984steeringmeetingroadmap20200529compilerteam287.html) * Meeting proposal: [rust-lang/compiler-team#287](https://github.com/rust-lang/compiler-team/issues/287) # Key notes and points from the meeting itself * Parallel compilation: * There was a general consensus to deprioritize parallel compilation in favor of pursuing better improvements to incremental compilation. * One interesting use case is CI turnaround times. Parallel compilation doesn't do much there since most CI systems are not very beefy. Incremental doesn't either, but it might if you enabled incremental support (and could trust it well enough). * We can still land some small PRs etc without it being on the roadmap necessarily. * Incremental compilation: * pnkfelix would like to get an incremental working group up and going. * simulacrum is interested in working on improving profiling. * impl Trait: we discussed a bit what it would take to finish up impl Trait. * How to drum up excitement: * WesleyWiser raised up the 2018 impl period as a really motivating and clear way to get involved: * ["I think one of the things I really liked about the 2018 impl period was that it created a really smooth ramp to get people involved with making the project goals happen."](https://zulip-archive.rust-lang.org/238009tcompilermeetings/94984steeringmeetingroadmap20200529compilerteam287.html#199164146) * A lot of the people who joined them, it seems, stuck around. * We discussed some of how we might recapture a bit of that spirit, with the thought that a big part of it * breaking down into a list of groups with goals * a marketing push advertising those rgoups and projects * identifying people who are happy to taker questons etc * We discussed "saying no" to some of the things on the list, notably a lot of them are assigned to nikomatsakis. # Initial proposal This section contains the proposal that was made up at the start of the meeting. ## General areas and themes These are not meant to be specific projects, but more categories that justify *why* we are pursuing specific projects. The categories include a bit of "what" that clarifies what the category is as well as "why" indicating why this is a category of work worth pursuing. * Improving the IDE experience * **Why?** In survey, a strong IDE experience was one of the top reasons given for "why I don't use Rust" or "what would make me use Rust more often", and the largest one that is directly under compiler team's control. * Improving build times for CI * **What?** From-scratch batch compilation performance * **What?** Integration with * **Why?** Anecdotal feedback that "interactive execution is ok, but CI is painful" * **Why?** Persistent complaint when it comes to large codebases especially * Polish and quality assurance * **What?** Fixing bugs, improving diagnostics * Deliver on long-standing features, finish things up * **Why?** Rust 2020 roadmap goal * **Why?** Anecdotally, a sense of "everything I want to use is always half-finished" has come up from numerous surveys (e.g., compiler team survey, a mozilla internal surveys) as well as frequent conversations. * Async polish and performance * **What?** Improving diagnostics, performance of async-await * **Why?** In survey, servers are the number one application for Rust. * Improving the way we organize ourselves * **What?** Structural changes to help us engage newcomers and be clearer in our priorities. * **Why?** Acting on the feedback from compiler-team survey that we need more prioritization and ability to communicate what we're doing. * **Why?** Help address the need * Improving incremental compilation * **What?** Making more source inputs incremental * **Why?** Improve local edit-compile-debug cycle * **What?** Increase test surface (e.g. discover new cases to test) * **Why?** Most incr-comp bugs reported do not have enough info for replication. * (An alternative here: Figure out ways to capture needed info automatically) ## Top goals for 2021 (Edition) These are actual specific projects. The idea here is to be thinking about "things that would be complete by mid 2021" -- but really I have in mind "what can we get done by 2020", per [Hofstadter's Law]. The list is perhaps too ambitious. It's not meant to be *exhaustive* necessarily, but it should I think try to identify the major things we think we can realistic accomplish and is meant to help us in driving our efforts. In particular, places where a single person is driving multiple projects are somewhat suspect and we should look carefully at which is the most important thing. It's better to do one thing completely than two things half-way, in other words. [Hofstadter's Law]: https://psychcentral.com/lib/hofstadters-law-and-realistic-planning/ For each goal, we list the following: * Motivation: one of the motivations above * Driver(s): people who are driving this work, if known (typically leads of groups) * Group(s): groups driving this work, if any * Goals for 2021: try to enumerate the thing we think we can accomplish in more detail ### Goals * Triage work * Motivation: Polish and quality assurance, Improving the way we organize ourselves * Driver(s): pnkfelix, spastorino * Group(s): wg-prioritization * Goals for 2021: * keep on keepin' on? * Keep the weekly triage meeting focused and on-time? * Rust-analyzer transition * Motivation: Improving the IDE experience * Driver(s): matklad, flodiebold * Groups(s): wg-rls * Goals for 2021: * moving rust-analyzer to be default IDE solution * rustc-dev-guide * Motivation: Improving the way we organize ourselves * Driver(s): spastorino * Group(s): wg-rustc-dev-guide * Goals for 2021: * Reorganized table of contents * Complete walk through? * Slowly fill out gaps in useful knowledge * Progress towards chalk integration * Motivation: Improving the IDE experience * Driver(s): nikomatsakis, flodiebold, jackh726 * Group(s): wg-rls, wg-traits * Goal for 2021: * rust-analyzer is using chalk, enable it to type-check and manage most projects * extract a shared library for types usable by rustc, chalk, and rust-analyzer * integrate experimentally with rustc and get to the point where `-Zchalk` allows things to largely work * MIR Optimizations * Driver(s): oli, wesleywiser * Group(s): wg-mir-opt * Goal for 2021: * Speed up compile-time by removing work llvm has to do * Speed up runtime by doing optimizations that llvm can't do or doesn't have the (type?) information in order to do. * Basically make idiomatic code as fast as handcrafted * Generic associated types * Driver(s): nikomatsakis, matthewjasper perhaps * Group(s): wg-traits? * Goal for 2021: * Have some form of GATs, including type-generic associated types, usable in rustc under a feature flag * Fix known soundness bugs * Const generics * Motivation: Deliver on long-standing features, finish things up * Driver(s): varkor? who else? * Group(s): XXX no project group at present * Why this feature? * Commonly cited in the Rust survey as one of the things people are most excited about * Blocks a number of language improvements, such as SIMD, `let x: [u32; _] = ...`, etc * Goal for 2021: * Correct the bug around the "generic parent" (blocked on lazy normalization) * Stabilize? Is that too ambitious? Can we clarify other goals? * Const evaluation * Motivation: Deliver on long-standing features, finish things up * Driver(s): oli, ralf, ecstatic-morse * Group(s): wg-const-eval, miri * Why this feature? * Commonly requested feature for embedded (very important there) and for replacing lazy_static things with compile-time things * Loads of finished features that need a bit of carrying over the stabilization line. * Improve the performance of the trait system * Driver(s): eddyb, to a lesser extent nikomatsakis * Goal: * Complete work described in [w3f#261](https://github.com/w3f/General-Grants-Program/pull/261) * Introduce major change proposals (MCP) * Motivation: Improving the way we work * Driver(s): nikomatsakis * Group(s): wg-meta * Goal for 2021: * See widespread use of MCPs for major changes * Introduce groups for major areas in the compiler as well as targets * Motivation: Improving the way we work * Driver(s): nikomatsakis, spastorino * Groups(s): wg-meta * Goal: * Create clearer folks that * RFC 2229 Implementation * Motivation: Deliver on long-standing features, finish things up * Driver(s): nikomatsakis, matthewjasper * Group(s): wg-rfc-2229 * Goal: * Land an initial version of the feature * Create a wg-incr-comp to focus on improvements to incremental compilation * Motivation: * Driver(s): pnkfelix, XXX? * Group(s) wg-incr-comp * Goal: * * Improving profiling infrastructure and self-profile * Motivation: Enabling other groups to establish metric-driven goals * Driver(s): simulacrum * Goals for 2021: * Be able to track disk space utilization of incremental, normal compilation * Track codegen unit splitting * impl Trait plan * Motivation: Deliver on long-standing features, finish things up * Driver(s): nikomatsakis, matthewjasper, oli-obk * Group(s): wg-impl-trait? * Goal: * Have to define the timeline, but basically clean up and deliver on impl Trait in various positions * Coordinate with lang team to see how much consensus we can get on other niggling questions * async-await polish * Motivation: Async polish and performance * Driver(s): tmandry, ...? * Group(s): wg-async-await * Goals for 2021: * Hard to define concretely, maybe we can? ## Awesome accomplishments I'd like to also note some of the awesome accomplishments we've had since Rust 2018. Let's list them out here: * self-profile and its integration into the perf page * Cross-lang ThinLTO and PGO (when did this ship?) * rustc-dev-guide has grown enormously * Const evaluation has made a ton of progress * MCP process introduced :tada: ## Projects not currently planned to move forward and why This is based on the discussion in the meeting. * Parallelization * Motivation: improving build times, but it's not clear which project above this helps (maybe CI) * Would need a good driver and plan * But the code does exist and there are real wins to be had here for people's experience, so quite possibly worth pursuing * Status for 2021: * In stasis * Might be willing to pursue, but it would require a real assessment of the plan and a set of committed people --- ### Minutes Design Meeting 2020 09 18 Mcp Retrospective (`content/minutes/design-meeting/2020-09-18-mcp-retrospective.md`) --- title: 2020-09-18 Major Change Proposal Retrospective type: docs --- # Links * [Zulip topic](https://zulip-archive.rust-lang.org/238009tcompilermeetings/01013designmeeting20200918MCPRetrospective.html) * Meeting proposal: [rust-lang/compiler-team#314](https://github.com/rust-lang/compiler-team/issues/314) # Key notes and points from the meeting itself - Feedback on MCPs after being seconded can be difficult to deal with. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210523197) - Some feelings of "where were you a week ago" as aluded to above - We do want to encourage feedback even if it's late but we should weigh some kinds of feedback more heavily than others "late" in the process. - Most common feedback was: [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210523836) - the problem of "MCP limbo", where there are MCPs that are not accepted but not clearly rejected - the problem of how we know if a concern is present and when it's "resolved" (who decides?) - the question of what to do about feedback after an MCP is accepted, and in particular MCPs for sweeping changes - We should probably be closing un-seconded MCPs after some amount of time [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210524064) - There should probably be a way for a contributor to keep an un-seconded MCP "alive". Possibly by leaving a comment to that effect. - That would extend the time before the MCP is closed but not indefinetly. Contributors would have to keep leaving comments if they want the MCP left open (this "friction" is probably a good thing). - @**pnkfelix** points out there isn't a good way to track these ideas after an MCP is closed. - Meeting participants generally seem ok with that. - There is ["fragile consensus"](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210525878) for auto-closing after a set amount of time has passed. - Discussion about "it's hard to track concerns" [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526028) - "Obvious" fix is to use rfcbot concerns - rfcbot concerns may not scale to such a large group as compiler-team + contributors [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526615) - A possible solution would be a small group of people whose responsibility would be to determine if concerns have been resolved sufficiently for the MCP to proceed. This likely overlaps a lot with the Technical Steering Committee idea which has been talked about before. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526748) - Discussion of specific rustbot commands [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210529314) - rustbot second -- marks this for approval after time elapses - rustbot close -- marks this for close after time elapses, unless a contributor leaves a comment - rustbot keepalive -- cancels a close - rustbot concern foo -- raises a concern, any team member/contributor can do it? (or anyone?) - rustbot resolve foo -- resolves a concern, any team member/contributor can do it - if an issue goes N weeks without activity (on the github thread), there is an automatic rustbot close - Discussion about MCPs that perhaps don't get enough attention [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210530507) - The biggest example of this is probably the recent MCPs that changed the `rust-lang/rust` repo directory structure and the `x.py` defaults. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210530930) - Some people didn't find out until after the fact and were unhappy with the approved changes. - For "large" or "controversial" MCPs, we may want to require a full FCP instead of simply a second. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210531323) - @**simulacrum** notes if there are conflicting veto/second comments, perhaps this should trigger a full FCP either immediately or within a certain amount of time if those concerns are not resolved. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210531397) [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210532435) - @**nikomatsakis** noted that the feedback from the survey showed nearly everyone agrees the MCP process is good for the team. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210532311) --- ### Minutes Steering Meeting 2018 10 26 (`content/minutes/steering-meeting/2018-10-26.md`) --- title: 2018-10-26 type: docs --- # 2018-10-26 We had our first T-compiler steering meeting today! What follows is a summary of the major points raised during the discussion. If you'd like to read the detailed minutes, please see the [Zulip chat log](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202018-10-26). I'll insert links here and there into that log where appropriate, if you want to see the original comment. To start, before the meeting we did a [survey](https://goo.gl/forms/m7QBFDpdvf7wik7k2) asking folks what they thought worked well and what needed improvement in and around with the compiler team. I summarized those results in a [Google doc](https://docs.google.com/spreadsheets/d/1HAq1D7OC616Nd_34olPalQi-EL4RDbBrsSO9ZZ6SJJc/edit?usp=sharing), which shows the things people wrote and how often (in the case of duplicates). We then voted on what to talk about (that's what the columns with the `x` are). In the end, we [opted to discuss](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550292) the most popular topic, which sort of subsumed a number of entries: - "how to plan what to do and expose our plans" - hard to answer "what to do next" or "how can I help" (8) - public roadmap (4) - hard to do high-level design + planning and not just triage (3) - no central place to get "big picture" of what's going on (3) (Originally, [we thought we'd cover many more things](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550335), but that did not turn out to be true. =) To start, there were a number of comments on the survey (and in the meeting) to support the idea that [Working Groups are an effective way to organize](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550475), [particularly for newcomers](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551682), [but it works best if we focus the WG on a concrete topic (e.g., NLL)](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550701). WG leaders ought to be actively triaging and looking for places to help people get involved, and so they can be good ones to answer the question of "what to do next". [We can also use WG as an organizational tool to expose the "big picture" of what's going on.](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550600) In addition to WGs, though, it [would be good to just list out the specialities of compiler team contributors, as well](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550683). WGs can also be an [organizational axis](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551729) for labels with the [WG focusing creating a steady supply of E-mentor issues](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551791). However, this places a big burden on WG leaders. One thing we noted is that [having more than one leader is good](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550547) and that [this itself can be a mentoring opportunity](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550696). In terms of getting people involved, the [findwork site was raised](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550848), as well as the difficulty of keeping it up to date ([perhaps WGs can help?](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136550929)). We pointed out that when we do our planning at [the next Rust All Hands](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551616), we can try to figure out WGs then. We discussed some how the [diagnostics efforts could be increased](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551512). We discussed [the rustc-dev-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552030) as well as the [NLL contributor YouTube videos](https://www.youtube.com/playlist?list=PLCQVvhKUrTN9VfaQx2AyOSAstwENaGkYA) and ways to improve them. One solid thought was that we might want to create a rustc-dev-guide WG ([which has its own zulip topic here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-guide-wg)). We talked in particular about how both [experienced folks and newcomers can contribute there](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552969). --- ### Minutes Steering Meeting 2018 11 16 (`content/minutes/steering-meeting/2018-11-16.md`) --- title: 2018.11.16 type: docs --- # 2018.11.16 The topic of today's steering meeting was [future planning](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147822055). Specifically, we were looking at some of the ideas we've had for major initiatives and trying to drill into them and make them more concrete. You can read the [full thread over on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202018-11-16). We began by [observing that the ultimate decisions we make here will be very influenced by the number of leaders we can find, and what they want to do](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147822224), and ultimately decided to [focus first on the technical angle](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147822373) before thinking about what leaders we have etc. We [made an initial breakdown of the work to be done into some big areas](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147822529), which was [later amended](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823187) with a [few more](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823299) areas: - parallelize with many threads - improving "batch compilation": - do what we do now, but better: - type-check faster, trait checking, etc - optimize MIR and generate better LLVM - do things better in the backend / improve ThinLTO ([link](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823284)) - avoid things like dsymutil - need to look at "time breakdown" across projects a bit perhaps? - defer, coallesce, and avoid work - multi-crate compilation model - MIR-only rlibs, which helps identify duplicates as well as dead code - "polymorphization" to coallesce monomorphized instances that have the same code - distribute and cache work across machines - improving RLS experience: - end-to-end queries - incrementalization - ... - "UX" improvements - continue compiling even when errors occur, particularly getting through to the borrow check phase ([link](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823465)) - error-message work - ... For the rest of this conversation, though, we [focused on batch compilation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823187). We discussed opportunities for getting estimates of the effectiveness of some of these ideas: - for [MIR-only rlibs](https://github.com/rust-lang/rust/issues/38913), mw [already did some of that work](https://github.com/rust-lang/rust/issues/38913#issuecomment-369584928). There is great potential, but we need effective parallelization. - thanks to hard work by Zoxc, mw, and others, we have a prototype parallel implementation, so [mw volunteered to gather some data](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147825002) - for [polymorphization](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823725), we can of course use LLVM's mergefunc to get some idea, but it [seems likely that we can find more opportunities than LLVM does](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824096), and of course we would also [operate earlier](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147823876) so the impact is larger. We would begin by doing an analysis over MIR -- **this would be a great place for someone who wants to work on a more weighty project to get involved**. - one concern is that [debuginfo and polymorphization may be tricky to combine](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824173) - in principle we should be able to see, for large projects, [how much code we wind up using in the end from dependencies](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824478), which might give us wins if we can defer that work through multi-crate compilation One question mark that was raised was how important it is to extend the query system further into the front-end of the compiler -- that code is [currently usually pretty fast relative to compilation as a whole](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824592). However, if we want to really transform the RLS experience, [we clearly need great progress here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824733). So to some extent this **may** come down to the [relative importance of RLS vs batch compilation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824754). Ultimately, the consensus was that we need to [**measure and get a clear idea where we are spending our time**](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824772) (shocker). A lot of these topics we've discussed above will require major architectural overhauls to the compiler, so one thing we discussed was the [desire to sketch out those refactorings and the dependencies between them](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147824592) into a kind of chart. We also talked about the need to "pay down" technical debt through cleanup refactorings, and how [those refactorings should be given high priority](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147825118). Finally, we talked some about how the [rustc crate graph](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-11-16/near/147825213) could stand for some reorganization -- this perhaps falls under technical debt. =) (Fun fact: we [initially split rustc into crates](https://github.com/rust-lang/rust/pull/19002) not for compilation time but rather because -- shortly before 1.0 -- the memory usage for compiling and linking the rustc crate was exceeding 4GB, preventing us from issuing builds on 32 bit machines.) ### Action items We enumerated some goals to try and get done before the next steering meeting. If you'd like to help with one of these tasks, let nikomatsakis know! - 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?) --- ### Minutes Steering Meeting 2018 12 14 (`content/minutes/steering-meeting/2018-12-14.md`) --- title: 2018.12.14 type: docs --- # 2018.12.14 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? [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202018-12-14 ["bus factor"]: https://en.wikipedia.org/wiki/Bus_factor A summary of the major points raised follows. If you prefer, you can [read the full transcript on Zulip][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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781649), perhaps in some kind of ["introduction to the compiler team" page on the repository](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781864) - this can help identify [where to direct your questions about code X](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781864) - but also where we need to increase the number of knowledgable people - it would be great if we had an [organized off-ramp system](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782070) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782619) - this is a [different sort of mentoring](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782971), 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"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782469). - we might try to actively increase bus factor via [fixing issues](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781737), writing tests, or writing docs - writing tests can be driven via [code coverage measurements](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782245) - writing docs can be driven via [`deny(missing_docs)`](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781803) as well as [push to complete the missing rustc-dev-guide sections](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781969) - one problem with writing documentation is that [there always seems to be something that is higher priority](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781986), maybe implying we need it as a roadmap item - a [dedicated `#t-compiler/help` stream](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782693) would be a good way to call attention and request mentoring - [maybe other streams as needed](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782111) - also, [documentation on how to use zulip seems like a win](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782350) ## 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784501): - ideally, [talk out the design on an internals thread to achieve some light consensus](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784204) - expect documentation [in the form of rustc-dev-guide chapters](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783865) - some examples where we should do this: - [end-to-end queries](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783972) - [parallel query execution](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784316) - in terms of the rustc-dev-guide: - it'd be [great to improve mdbook to permit for graphs](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783887) - maybe we can [add graphviz support into mdbook](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784431) - we should [not neglect doc comments](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784445) - and we can link [back](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784542) and [forth](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784551) [copiously](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784688) (and [make sure we check for dead links](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784647)) --- ### Minutes Steering Meeting 2019 01 04 (`content/minutes/steering-meeting/2019-01-04.md`) --- title: 2019.01.04 type: docs --- # 2019.01.04 [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04) We discussed the upcoming Rust All Hands. We have a [HackMd document][doc] that lists a bunch of ideas for what to talk about, but mostly we talked about how to structure the meeting itself. [doc]: https://hackmd.io/Wbnday_dQxSy-iPWLm33Rg We summarized [how the All Hands was structured last year](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154414708): 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154414981), which could [help people unfamiliar with an area get up to speed](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415043). In general, we decided that each of our slots should begin with [some exposition of "how things work now"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415298), 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415252), e.g., rustdoc or RLS. We discussed some possibler areas for discussion: - [the rustc-dev-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415509) - [related work, like RLS, rustdoc,](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415505) or [cranelift](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415743) - [mentoring?](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415632) - maybe, but we have to figure out specifically what - [salsa, polonius, chalk, etc](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415977) - [diagnostics](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154416365) On the topic of IDEs, it would be useful to [hear from Matklad about rust-analyzer](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415886). We also thought a bit about some more "radical" ideas that might be worth making a bit more concrete: - [downloading pre-compiled artifacts](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154416722) - [compiling all configurations at once for docs, IDE](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154416819) --- ### Minutes Steering Meeting 2019 01 17 (`content/minutes/steering-meeting/2019-01-17.md`) --- title: 2019.01.17 type: docs --- # 2019.01.17 [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17) We [discussed the upcoming Rust All Hands](https://rust-lang.zulipchat.coma/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156373953). 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374223). [Our goal is to have this list complete before the all hands](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375133). Our [initial list](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374353) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374713). In general, we felt we [needed some form of concrete incentive](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374924), similar to how [performance optimization gets you that nice green bar](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374984). To that end we talked about: - [maybe we can set some specific documentation targets?](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374831) For example, enabling `deny(missing_docs)` by summer. - or identify some other form of [doc coverage metric](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156374860) - we might also [block PRs that lower the doc threshold](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375096) - in general, this seemed like a good topic to revist under a ["compiler team governance and apprenticeship" meeting at all hands](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375119) In terms of the all hands, one idea for a [possible outcome is to try and produce a "slew of technical design RFCs"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375133), 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"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375466), where a ["plan" includes who will do what](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375486). One possibility is having ["breakout sessions"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156375605) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156376045). 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156376208), and it's [nice for people to be able to review it at their liesure](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156376209). When it comes to the RLS, [we decided to take a "tech first" approach](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156376502) -- 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/ide.20design.20meeting)). For the "second most important topic", [we settled on "organizational questions"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156377313). The ["root goal" of any organizational alternatives would be](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156377810): - 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156377556). 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156377808) (unless they are eddyb). [Concluding comment](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-17/near/156378043): > 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. --- ### Minutes Steering Meeting 2019 03 01 (`content/minutes/steering-meeting/2019-03-01.md`) --- title: 2019.03.01 type: docs --- # 2019.03.01 [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E01.20.2358850/near/159650062) Before the meeting started, [@nikomatsakis][nikomatsakis] proposed an agenda and linked to a [document to collect agenda ideas](https://hackmd.io/wsHwsi9zR3iq0ZF2SgEq9Q) for future meetings. Also, [@mw][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][draft_policy] was already in-progress by [@davidtwco][davidtwco]. The meeting commenced with a call for involvement in the [RLS 2.0 working group][rls2] led by [@matklad][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][davidtwco], [@pnkfelix][pnkfelix] and [@Xanewok][Xanewok] mentioned that they would endeavour to find some time to dig into RLS 2.0. Next, [@nikomatsakis][nikomatsakis] announced an ongoing effort by [@spastorino][spastorino] to collate an [expert map](https://hackmd.io/Izvor8KZRiqUgcUyd2CYTw) 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][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][polonius], [chalk][chalk] and the upcoming diagnostics refactoring). The [current draft of the policy][draft_policy] was linked and [@davidtwco][davidtwco] emphasised that it was very much a draft and there are lots of unresolved questions. [@nikomatsakis][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][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. Both [@nikomatsakis][nikomatsakis] and [@mw][mw] wanted there to be a simple guide to follow for creating out-of-tree crates - this should include links to examples and things to copy-and-paste. [@pnkfelix][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][nikomatsakis] mused that making libraries too general purpose could carry a higher maintainance/breaking-change burden. [@mw][mw] suggested that this would need to be decided on a case-by-case basis. [@nikomatsakis][nikomatsakis] clarified that we should absolutely be following semver in these crates. [@nikomatsakis][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][pnkfelix] suggested that long-term we might want in-tree tests of these crates to guarantee that they maintain compatibility. [@mw][mw] then proposed walking through an example - the [self-profile working group][self_profile] 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][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][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][nikomatsakis] noted that it would be great for active working group members to have the opportunity to gain r+. [@mw][mw] asked if we would set up community infrastructure (such as Zulip instances or streams) for the out-of-tree crates, but [@nikomatsakis][nikomatsakis] thought it best that this be tied to the community infrastructure already in-place for the working group. Then, [@nikomatsakis][nikomatsakis] re-raised the question of whether these out-of-tree crates are best kept in the rust-lang organization. [@mw][mw] suggested that this is best as it simplifies bors and highfive integration and would use existing team permissions. [@pnkfelix][pnkfelix] asked how challenging migration from a personal repository to the rust-lang organization is. On this point, [@nikomatsakis][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][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][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][mw] asked if there were any example workflows for handling changes in external crates to which [@nikomatsakis][nikomatsakis] suggested that a rustc-dev-guide chapter on that and how to make local copies for debugging would be necessary. [@davidtwco][davidtwco] asked what information should be kept in the policy document and what information should be kept in the rustc-dev-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][mw] then raised the question of where consent of compiler team members should be gathered before creating new out-of-tree crates. [@pnkfelix][pnkfelix] suggested it could be a triage meeting item and [@nikomatsakis][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][mw] mused that something asynchronous would be preferred and that agreement within the working group itself should come first. [@nikomatsakis][nikomatsakis] suggested that the goals of approval should be discussed, such as helping to pick a suitable name. [@mw][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][davidtwco] then agreed to write these minutes and his hands are starting to get tired at this point. [rls2]: ../../../working-groups/rls-2.0 [self_profile]: ../../../working-groups/self-profile [draft_policy]: https://github.com/rust-lang/compiler-team/pull/19 [chalk]: https://github.com/rust-lang-nursery/chalk/ [polonius]: https://github.com/rust-lang-nursery/polonius [davidtwco]: https://github.com/davidtwco [nikomatsakis]: https://github.com/nikomatsakis [pnkfelix]: https://github.com/pnkfelix [Xanewok]: https://github.com/Xanewok [matklad]: https://github.com/matklad [mw]: https://github.com/michaelwoerister [spastorino]: https://github.com/spastorino [wesleywiser]: https://github.com/wesleywiser --- ### Minutes Steering Meeting 2019 03 22 (`content/minutes/steering-meeting/2019-03-22.md`) --- title: 2019.03.22 type: docs --- # 2019.03.22 [Zulip topic.](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850) ## Announcements - [oli-obk](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161450157) mentions that wg-diagnostics is planning [to use the annotate-snippets crate](https://github.com/rust-lang/rust/issues/59346) within rustc. - [nikomatsakis](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161450198) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161450307) almost has a series of PRs pushing queries all the way back to parsing. - [davidtwco](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161450922) has, [after numerous attempts](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161451008), managed to produce a have a working branch that unblocks RFC 2008. - [pnkfelix](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161455043) applauds oli-obk's [fixmeh project](https://oli-obk.github.io/fixmeh/), which lists all the FIXME comments in the compiler. ## Main topic 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](https://paper.dropbox.com/doc/Compiler-team-tasks-and-roles--AZ3lQbJIE85P1R6~Xku6qL0RAg-TZxdEmmzMTD049QvEG4Li) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161452801) - [Thoughts about the "office hours" concept](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161453525) - [What we can do about status updates](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161454477) - [lolbench](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E03.2E22.20.2358850/near/161461620), the project to measure and track the performance of generated code --- ### Minutes Steering Meeting 2019 04 12 (`content/minutes/steering-meeting/2019-04-12.md`) --- title: 2019.04.12 type: docs --- # 2019.04.12 [Zulip topic.](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850) ## Announcements - [nikomatsakis](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163192566) has opened a [PR with a draft RFC](https://github.com/rust-lang/compiler-team/pull/52) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193094) is nearing completion on their work on the symbol naming revamp. It [might even offer some performance improvements](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193354). - [nikomatsakis](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193402) mentioned that in the [wg-traits meeting on Monday](https://calendar.google.com/event?action=TEMPLATE&tmeid=NnViNzZxN252dGZ2ZHRvNTdnN2dpbGo2NjRfMjAxOTA0MTVUMTgwMDAwWiA2dTVycnRjZTZscnR2MDdwZmkzZGFtZ2p1c0Bn&tmsrc=6u5rrtce6lrtv07pfi3damgjus%40group.calendar.google.com&scp=ALL) 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. ## Main topic Our [main topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193454) 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](https://gist.github.com/nikomatsakis/3afbec52758741727e4535d973bb0667) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193679)) - In other cases, people might be bringing an existing idea for evaluation and broader discussion, looking to reach a conclusion. ([Example](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163193734)) 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.](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194111) For "early stage" discussions, the proposal might be fairly sparse. ([Perhaps like this example](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194566).) For meetings that aim to reach firm decisions, [the proposals would be expected to contain more details](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194229); it would be useful to list [things the author expects are hard to do](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194768) and also points where there are [design decisions to be made](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194846). 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194881), since people can lurk in the meetings and soak up details ([not to mention the paper trail](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163194320)). 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"](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195057). In particular, [we don't want to be doing designs unless there are people who will put them into practice](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163198133). 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195743) 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](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195172), even if the people *making* the design are busy with other things. Similarly, [design documents can become the basis for rustc-dev-guide chapters](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195352). [We plan to flesh out some more details and put this idea into action starting May 3rd (the next steering meeting).](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163198505) --- ### Minutes Triage Meeting 2019 04 11 (`content/minutes/triage-meeting/2019-04-11.md`) --- title: 2019.04.11 type: docs --- # 2019-04-11 # Volunteers wanted - seeking help on resolving ["[firefox] error: relocation refers to local symbol "" [12], which is defined in a discarded section"](https://github.com/rust-lang/rust/issues/59652) - seeking help on resolving ["Compiler panic with generic-typed nested closures"](https://github.com/rust-lang/rust/issues/59494) # Backport decisions - No backport decisions were made at this meeting because there were no PRs nominated for backport. # Working group sync ## [wg-mir-opt](../../../working-groups/mir-opt/) - The current goal is to make the MIR `Place` data structure non-recursive ([Issue #52708](https://github.com/rust-lang/rust/issues/52708)). This should use less memory, be easier to work with, and probably faster as well. - After that is completed, there are a number of other `Place` related refactorings and other ideas from the All-Hands meeting that can be worked on. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-11.20.2354818/near/163105192) ## [wg-pipelining](../../../working-groups/pipelining/) - The goal is to allow Cargo to invoke rustc sooner letting downstream crates start compiling while upstream crates do LLVM work ([Issue #58465](https://github.com/rust-lang/rust/issues/58465)) - This working group is just getting started and had its initial meeting on 4/5. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-11.20.2354818/near/163106257) --- ### Minutes Triage Meeting 2019 04 18 (`content/minutes/triage-meeting/2019-04-18.md`) --- title: 2019.04.18 type: docs --- # 2019-04-18 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - There were no beta backport nominations this week. - "Use informational target machine for metadata" ([#58605](https://github.com/rust-lang/rust/pulls/58605)) was nominated for backport to stable. - [Nomination was declined](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-18.20.2354818/near/163655391) ## Working group sync ### [wg-llvm](../../../working-groups//llvm) - `wg-llvm` is working on optimizing `overflow` intrinsics with `add` and `sub` instructions. - A PR ([#59546](https://github.com/rust-lang/rust/pull/59546)) has also been opened to fix [a long standing unsoundness issue](https://github.com/rust-lang/rust/issues/28728). The PR is currently waiting for someone to run lolbench.rs to determine what impact the PR has on generated code performance. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-18.20.2354818/near/163658733) ### [wg-async-await](../../../working-groups/async-await/) - `wg-async-await` is currently working though the list of [issues blocking stabilization](https://github.com/rust-lang/rust/labels/AsyncAwait-Blocking). - This includes: - [Async-await syntax](https://github.com/rust-lang/rust/issues/60016) - [Supporting async fns whose arguments have multiple lifetimes](https://github.com/rust-lang/rust/issues/56238) - [Shrinking the size of generators](https://github.com/rust-lang/rust/issues/52924) - The thorniest issue remaining is determining the drop order for unused async function arguments ([#54716](https://github.com/rust-lang/rust/issues/54716)) - While investigating this issue, some subtle inconsistencies regarding existing drop order for regular functions were discovered. - This issue is also not proving to be easy to resolve. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-18.20.2354818/near/163658872) --- ### Minutes Triage Meeting 2019 04 25 (`content/minutes/triage-meeting/2019-04-25.md`) --- title: 2019.04.25 type: docs --- # 2019-04-25 ## Volunteers wanted - Somebody needed to reduce [#60136](https://github.com/rust-lang/rust/issues/60136) - Somebody needed to write documentation [#60059](https://github.com/rust-lang/rust/issues/60059) ## Backport decisions - "Temporarily accept [i|u][32|size] suffixes on a tuple index and warn" [#60186](https://github.com/rust-lang/rust/issues/60186) - [Accepted](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-25.20.2354818/near/164176203) - "Revert "compile crates under test w/ -Zemit-stack-sizes" [#59911](https://github.com/rust-lang/rust/issues/59911) - [Accepted](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-25.20.2354818/near/164176203) ## Working group sync ### [wg-rfc-2229](../../../working-groups/rfc-2229/) - RFC 2229 is a proposal to change how closures capture variables. Instead of capturing the complete variable when a part of it is used (ie `foo.bar`), only the "path" will be captured by the closure. - This requires a large amount of refactoring in the compiler. - There is currently a PR open which implements part of this but it regresses compiler error messages in some situtations. - There's been ongoing discussion as to next steps and other refactorings some of which have issues with light mentoring steps available. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-25.20.2354818/near/164176279) ### [wg-self-profile](../../../working-groups/self-profile/) - wg-self-profile has been making progress toward the "minimum viable product" tracking issue [#58967](https://github.com/rust-lang/rust/issues/58967): - A crate called measureme has been created which handles serializing and deserializing profiler events to a compact binary format. - The crate has been integrated with the existing self-profile infrastructure in rustc. - There are now summarization and flamegraph tools for processing the profiler data in the repo as well. - The next step is to work on integrating the summarization tool with perf.rlo. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-04-25.20.2354818/near/164177123) --- ### Minutes Triage Meeting 2019 05 02 (`content/minutes/triage-meeting/2019-05-02.md`) --- title: 2019.05.02 type: docs --- # 2019-05-02 ## Volunteers wanted - call for assistance: Does someone have an ARM (and maybe also MUSL?) host they could use to try to replicate ["Stable rustc always panics on arm/musl"](https://github.com/rust-lang/rust/issues/60297) ## Backport decisions - There were no beta- nor stable-nominations for backport. ## Working group sync ### [wg-meta](../../../working-groups/meta) - The compiler contributor RFC is in FCP and should be merged soon. - They are trying to get some sort of "design meeting" up and going. The plan is to discuss that initial proposal in more depth tomorrow at steering meeting, and then get started after that. - The compiler-team repo has a list of issues tracking things that wg-meta would like to get done. - call for assistance: [Convert the compiler-team repo to use GitHub pages](https://github.com/rust-lang/compiler-team/issues/73) ### [wg-rls-2.0](../../../working-groups/rls-2.0/) - Lots of progress happening! - Work is being done to expand macros by example so the analyser can understand the generated code. - Chalk is being integrated ([#1216](https://github.com/rust-analyzer/rust-analyzer/pull/1216)). - The rustc lexer code is being extracted into a separate crate ([#60261](https://github.com/rust-lang/rust/pull/60261)). --- ### Minutes Triage Meeting 2019 05 09 (`content/minutes/triage-meeting/2019-05-09.md`) --- title: 2019.05.09 type: docs --- # 2019-05-09 ## Volunteers wanted - compiler panic "randomly" with incremental build [(#60629)](https://github.com/rust-lang/rust/issues/60629) - [Help is wanted to reproduce the issue](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-05-09.20.2354818/near/165255081) - Regression: Typemap type mismatch in 1.34.0+ [(#60375)](https://github.com/rust-lang/rust/issues/60375) - [Help is wanted to narrow down the problem](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-05-09.20.2354818/near/165255267) ## Backport decisions - save-analysis: Fix ICE when processing associated constant [(#60649)](https://github.com/rust-lang/rust/pull/60649) - Backport accepted ## Working group sync ### [wg-nll](../../../working-groups/nll/) - [NLL migration mode is enabled on Rust 2015](https://github.com/rust-lang/rust/pull/59114). - The next goal is to remove the old AST-based borrow checker. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-05-09.20.2354818/near/165259126) ### [wg-diagnostics](../../../working-groups/diagnostics/) - wg-diagnostic's current goal is to pull some of the diagnostic infrastructure out of the compiler and into a reusuable crate. - They are working on organizing their first meeting soon. - [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-05-09.20.2354818/near/165259007) --- ### Minutes Triage Meeting 2019 05 16 (`content/minutes/triage-meeting/2019-05-16.md`) --- title: 2019.05.16 type: docs --- # 2019-05-16 ## Volunteers wanted - request for investigation: "Compiler panic with generic-typed nested closures" ([#59494](https://github.com/rust-lang/rust/issues/59494)) - request for investigation: "Exponential compile-time and type_length_limit blowup when nesting closure wrappers" ([#54540](https://github.com/rust-lang/rust/issues/54540)) - eddyb has excellent notes [here](https://github.com/rust-lang/rust/issues/54540#issuecomment-485240110) on the fundamental problem - request for investigation: "llvm lint: "Undefined behavior: Call argument type mismatches callee parameter type" with mixing debug and release" ([#48310](https://github.com/rust-lang/rust/issues/48310)) - specifically, we need to resolve whether this is in fact an LLVM bug - request for investigation: "ICE with unsized associated type" ([#60431](https://github.com/rust-lang/rust/issues/60431)) ## Backport decisions - save-analysis: Pull associated type definition using qpath_def" ([#59894](https://github.com/rust-lang/rust/pull/59894)) - Backport accepted - Use delay_span_bug for error cases when checking AnonConst parent ([#60710](https://github.com/rust-lang/rust/pull/60710)) - Backport accepted - Use delay_span_bug for "Failed to unify obligation" ([#60644](https://github.com/rust-lang/rust/pull/60644)) - Backport accepted - Instead of ICEing on incorrect pattern, use delay_span_bug ([#60641](https://github.com/rust-lang/rust/pull/60641)) - Backport accepted - conditionally modify darwin targets to macosx targets with versions ([#60378](https://github.com/rust-lang/rust/pull/60378)) - Backport declined - default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targets ([#60788](https://github.com/rust-lang/rust/pull/60788)) - Backport declined ## Working group sync - We ran out of time to hear from working groups in this meeting. --- ### Minutes Triage Meeting 2019 05 23 (`content/minutes/triage-meeting/2019-05-23.md`) --- title: 2019.05.23 type: docs --- # 2019-05-23 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - "Fix ICE with inconsistent macro matchers" ([#61046](https://github.com/rust-lang/rust/pull/61046)) - Backport accepted - "debuginfo: Revert to old/more verbose behavior for -Cdebuginfo=1" ([#61007](https://github.com/rust-lang/rust/pull/61007)) - Backport accepted ## Working group sync ### [wg-pgo](../../../working-groups/pgo/) - PGO stands for Profiler Guided Optimization. - Code is instrumented and then run. The profilng data gathered at runtime is then used in subsequent compilations to guide optimizations. - PGO support is almost complete! - The remaining work is mostly just around the UI side of things: documenting compiler flags, moving flags from `-Z` to `-C`. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-05-23.20.2354818/near/166368190) --- ### Minutes Triage Meeting 2019 06 06 (`content/minutes/triage-meeting/2019-06-06.md`) --- title: 2019.06.06 type: docs --- # 2019-06-06 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - Fix regression 61475 [#61500](https://github.com/rust-lang/rust/pull/61500) - Backport approved - Turn turbo :fish: :ice_cream: into an error [#61189](https://github.com/rust-lang/rust/pull/61189) - Backport approved - Fix overflowing literal lint in loops [#61098](https://github.com/rust-lang/rust/pull/61098) - Backport approved - Fix more escaping ReScopes [#60765](https://github.com/rust-lang/rust/pull/60765) - Backport approved - Constrain all regions in the concrete type for an opaque type [#60449](https://github.com/rust-lang/rust/pull/60449) - Backport approved ## Working group sync ### [wg-mir-opt](../../../working-groups/mir-opt/) - const propagation (by Wesley Wiser) on mir opt level 2 - some great compile-time speedups due to llvm and later MIR passes having less to do - [Perf](https://perf.rust-lang.org/compare.html?start=7cdaffd7962c4aae0cadd82baa241901b03f9458&end=78f9292a51479346f19ce2c71bdb0db551ce8fe5) (active PR) has some regressions (up to 4% though) - rewrite loads of recursive Place algorithms imperatively (by Santiago Pastorino) - WIP PR by Santiago Pastorino for making Place a struct instead of an enum (preliminary work for making projections a slice instead of a recursive enum) [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-06-06.20.2354818/near/167489269) ### [wg-pgo](../../../working-groups/pgo/) - Nothing new to report --- ### Minutes Triage Meeting 2019 06 13 (`content/minutes/triage-meeting/2019-06-13.md`) --- title: 2019.06.13 type: docs --- # 2019-06-13 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - Handle index out of bound errors during const eval without panic [#61598](https://github.com/rust-lang/rust/pull/61598) - Approved for beta backport. ## Working group sync ### [wg-llvm](../../../working-groups/llvm/) - Nikita Popov fixed a codegen issue with LLVM float min/max intrinsics on X86. - This allowed varkor to switch our min/max functions to use those intrinsics. - Nikita Popov is working on getting CVP nowrap inference reenabled in LLVM. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-06-13.20.2354818/near/168041753) ### [wg-async-foundations](../../../working-groups/async-await/) - The [list of blocking issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AAsyncAwait-Blocking) is shrinking! - Two major issues have had signficant work done on them: - nikomatsakis posted a PR which closes a number of lifetime related issues. - tmandry is working on shrinking the size of futures. - Work is commencing on the "async book" which will help explain how async I/O works and the async-await feature in particular. - Many more tests need to be written around the feature. - This might be a good way to get involved with the working group! [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-06-13.20.2354818/near/168052951) --- ### Minutes Triage Meeting 2019 06 20 (`content/minutes/triage-meeting/2019-06-20.md`) --- title: 2019.06.20 type: docs --- # 2019-06-20 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - Beta: "resolve: Temporarily make panic available with no_implicit_prelude" [#61971](https://github.com/rust-lang/rust/pull/61971) - Backport accepted - Beta: "Fix ICE involving mut references" [#61947](https://github.com/rust-lang/rust/pull/61947) - Backport accepted - Beta: "rustc_typeck: correctly compute Substs for Res::SelfCtor." [#61896](https://github.com/rust-lang/rust/pull/61896) - Backport accepted - Beta: "Fix rust-lldb wrapper scripts." [#61827](https://github.com/rust-lang/rust/pull/61827) - Backport declined - Beta: "Fix cfg(test) build for x86_64-fortanix-unknown-sgx" [#61503](https://github.com/rust-lang/rust/pull/61503) - Backport accepted - Beta: "Dont ICE on an attempt to use GAT without feature gate" [#61118](https://github.com/rust-lang/rust/pull/61118) - Backport accepted - Beta: "Limit dylib symbols" [#59752](https://github.com/rust-lang/rust/pull/59752) - Backport accepted - Beta: "create a "provisional cache" to restore performance in the case of cycles" [#61754](https://github.com/rust-lang/rust/pull/61754) - We're going to wait a week and then revisit this - Beta: "Hygienize macros in the standard library" [#61629](https://github.com/rust-lang/rust/pull/61629) - Backport accepted ## Working group sync There wasn't time to check-in with the working groups this week. --- ### Minutes Triage Meeting 2019 06 27 (`content/minutes/triage-meeting/2019-06-27.md`) --- title: 2019.06.27 type: docs --- # 2019-06-27 The meeting largely consisted of discussion of a few nominated issues: - [Rustdoc recursion limit issue](https://github.com/rust-lang/rust/issues/62059) - Assigned to @nagisa - [Incorrect span / broken rustfix: help: use dyn: dyn #[dom_struct]](https://github.com/rust-lang/rust/issues/61963) - @davidtwco is assigned and working on a fix. - [Soundness hole in pattern matching on enums with an uninhabited variant](https://github.com/rust-lang/rust/issues/61696) - Assigned to @eddyb. - [Self as default type isnt typechecked](https://github.com/rust-lang/rust/issues/61631) - Under discussion at a future T-Lang meeting. - [Incremental compilation results in linker error when method use is removed](https://github.com/rust-lang/rust/issues/59535) - Assigned to @Zoxc tentatively as @mw is on leave. - [Coherence can be bypassed by an indirect impl for a trait object](https://github.com/rust-lang/rust/issues/57893) - Assigned to @centril and it has a T-Lang meeting slot. - [The compiler should report publicly exported type names if possible](https://github.com/rust-lang/rust/issues/21934) - There was some discussion about why this is difficult currently and possible approaches to resolving this issue. - No firm conclusion was reached so the nomination label was left on the issue and it can be picked back up next week. - ["immutable field" errors are confusing when the handle is mutable, should describe why it is immutable](https://github.com/rust-lang/rust/issues/18150) - This issue is `P-high` for WG-diagnostics but not necessarily the entire compiler team. --- ### Minutes Triage Meeting 2019 07 04 (`content/minutes/triage-meeting/2019-07-04.md`) --- title: 2019.07.04 type: docs --- # 2019-07-04 ## Volunteers wanted - No issues discussed this week. ## Backport decisions - There were no backport nominations this week. ## Working group sync [wg-meta](https://github.com/rust-lang/compiler-team/blob/master/content/working-groups/meta/_index.md) - Conferences, Mozilla All-Hands, and other activities have been keeping members of the group busy recently. So there's been a slight stall in activity. - The compiler team website is nearly completed thanks to @Federico Carrone and @catalinasy! [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-07-04.20.2354818/near/169654430) ## Meta A [poll was taken](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-07-04.20.2354818/near/169652882) to see if there was interest in moving the Friday Compiler Steering Meeting to another day or time. Most people didn't have a strong feeling one way or the other. --- ### Minutes Triage Meeting 2019 07 11 (`content/minutes/triage-meeting/2019-07-11.md`) --- title: 2019.07.11 type: docs --- # 2019-07-11 ## Volunteers wanted - No issues discussed this week. ## Backport nominations - [Raise the default recursion limit to 128](https://github.com/rust-lang/rust/pull/62450) - Approved for beta backport - [Fix ICEs when Self is used in type aliases](https://github.com/rust-lang/rust/pull/62417) - Approved for beta backport - [Emit warning when trying to use PGO in conjunction with unwinding on Windows](https://github.com/rust-lang/rust/pull/61853) - On hold while @wesleywiser looks into alternative approaches ## Working group sync [wg-pipelining](https://github.com/rust-lang/compiler-team/blob/master/content/working-groups/pipelining/_index.md) - Tracking issue [#60988](https://github.com/rust-lang/rust/issues/60988) - @alexcrichton is proposing we stabilize the feature and turn it on for everyone by default. There are two main parts to this: - [A `--json` flag which will replace `--json-rendered`](https://github.com/rust-lang/rust/issues/60987#issuecomment-509310492) - [JSON notifications when artifacts are complete](https://github.com/rust-lang/rust/issues/60419#issuecomment-502228173) --- ### Minutes Triage Meeting 2019 07 18 (`content/minutes/triage-meeting/2019-07-18.md`) --- title: 2019.07.18 type: docs --- # 2019-07-18 ## Volunteers wanted - No issues discussed this week. ## Backport nominations - [Fix #62660](https://github.com/rust-lang/rust/pull/62668) - Approved for beta backport - Declined for stable backport - [Cancel unemitted diagnostics during error recovery](https://github.com/rust-lang/rust/pull/62666) - Approved for beta backport - [Handle errors during error recovery gracefully](https://github.com/rust-lang/rust/pull/62604) - Approved for beta backport - [Correctly break out of recovery loop](https://github.com/rust-lang/rust/pull/62607) - Approved for beta backport - Declined for stable backport - [Emit warning when trying to use PGO in conjunction with unwinding on Windows](https://github.com/rust-lang/rust/pull/61853) - Declined because it's supersceeded by [#62615](https://github.com/rust-lang/rust/pull/62615) - [Only error about MSVC + PGO + unwind if we're generating code](https://github.com/rust-lang/rust/pull/62615) - Approved for beta backport - [rustc_target: avoid negative register counts in the SysV x86_64 ABI](https://github.com/rust-lang/rust/pull/62380) - Approved for beta backport ## Working group sync There wasn't time for a working group sync this week. --- ### Minutes Triage Meeting 2019 07 25 (`content/minutes/triage-meeting/2019-07-25.md`) --- title: 2019.07.18 type: docs --- # 2019-07-25 ## Volunteers wanted - [#60297](https://github.com/rust-lang/rust/issues/60297) - we are looking for someone with access to ARM/musl to help debug this - [#62896](https://github.com/rust-lang/rust/issues/62896) and [#62932](https://github.com/rust-lang/rust/issues/62932) - there are some embedded failures, quite possibly related to LLVM, that could use bisection ## Backport nominations - [Make the parser TokenStream more resilient after mismatched delimiter recovery](https://github.com/rust-lang/rust/pull62887) - Approved for beta backport ## Working group sync No working group sync this week. --- ### Minutes Triage Meeting 2019 08 01 (`content/minutes/triage-meeting/2019-08-01.md`) --- title: 2019.08.01 type: docs --- # 2019-08-01 ## Volunteers wanted No issues discussed this week. ## Backport decisions There were no pending backport decisions this week. ## Working group sync No working group sync this week. --- ### Minutes Triage Meeting 2019 08 15 (`content/minutes/triage-meeting/2019-08-15.md`) --- title: 2019.08.15 type: docs --- # 2019-08-15 ## Volunteers wanted - [#60297](https://github.com/rust-lang/rust/issues/60297) - we are looking for someone with access to ARM/musl to help debug this ## Backport nominations - [#63508](https://github.com/rust-lang/rust/pull/63508) Do not ICE when synthesizing spans falling inside unicode chars - Beta backport accepted ## Working group sync ### [wg-rustc-dev-guide](https://rust-lang.github.io/compiler-team/working-groups/rustc-dev-guide/) wg-rustc-dev-guide's objective is to make the compiler easier to learn by ensuring that rustc-dev-guide is "complete". Currently they're working on: 1. Getting [video lectures](https://www.youtube.com/watch?v=mAUGvNgZYtw) about parts of the compiler from people who know them 2. Turning existing video lectures into content for the [rustc-dev-guide](https://github.com/rust-lang/rustc-dev-guide) 3. Triaging and working on issues and pull requests for rustc-dev-guide content Help is always wanted! [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-08-15.20.2354818/near/173295057) --- ### Minutes Triage Meeting 2019 08 29 (`content/minutes/triage-meeting/2019-08-29.md`) --- title: 2019.08.29 type: docs --- # 2019-08-29 ## Volunteers wanted - We've had a few issues recently related to upgrading LLVM. We'd like to create a [new working group](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-08-29.20.2354818/near/174456953) which will focus on fixing ICEs and miscompilations caused by LLVM. ## Backport nominations - Account for doc comments coming from proc macros without spans [#63930](https://github.com/rust-lang/rust/pull/63930) - Accepted for beta backport - fix nounwind attribute logic [#63909](https://github.com/rust-lang/rust/pull/63909) - Declined for beta backport - Fix nested eager expansions in arguments of format_args [#63717](https://github.com/rust-lang/rust/pull/63717) - Accepted for beta backport - Don't access a static just for its size and alignment [#62982](https://github.com/rust-lang/rust/pull/62982) - Accepted for beta backport - debuginfo: give unique names to closure and generator types [#63875](https://github.com/rust-lang/rust/pull/63875) - Accepted for beta backport ## Working group sync ### [wg-mir-opt](https://rust-lang.github.io/compiler-team/working-groups/mir-opt/) - [@spastorino](https://github.com/spastorino) has gotten Place 2.0 (a reimagining of `mir::Place` using slices for projections) with only a slight regression in memory usage on one compiler benchmark. - They're currently working on fixing that regression. - [@wesleywiser](https://github.com/wesleywiser) split promoted items out of `mir::Body` to prevent cycles in the optimization pipeline. - They're continuing to work on making the `const_prop` pass more powerful. [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-08-29.20.2354818/near/174460086) ### [wg-nll](https://rust-lang.github.io/compiler-team/working-groups/nll/) - A few soundess "fixed-by-nll" issues were closed recently. - Work is ongoing to stabilize bind-by-move pattern guards. [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-08-29.20.2354818/near/174460730) ### [wg-parallel-rustc](https://rust-lang.github.io/compiler-team/working-groups/parallel-rustc/) - [@aturon](https://github.com/aturon) is doing an audit of related PRs (accepted and pending) with a focus on shared state and lock semantics with multithreaded rustc. - [@aturon](https://github.com/aturon) is also going to be working on reducing locking and shared mutable state that exists outside the query system. [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-08-29.20.2354818/near/174461122) --- ### Minutes Triage Meeting 2019 09 05 (`content/minutes/triage-meeting/2019-09-05.md`) --- title: 2019.09.05 type: docs --- # 2019-09-05 ## Volunteers wanted ## Backport nominations - Update xLTO compatibility table in rustc book [#64092](https://github.com/rust-lang/rust/pull/64092) - Approved for beta backport - Support "soft" feature-gating using a lint [#64066](https://github.com/rust-lang/rust/pull/64066) - Approved for beta backport - pprust: Do not print spaces before some tokens [#63897](https://github.com/rust-lang/rust/pull/63897) - Approved for beta backport ## Working group sync No working group sync this week. --- ### Minutes Triage Meeting 2019 09 12 (`content/minutes/triage-meeting/2019-09-12.md`) --- title: 2019.09.12 type: docs --- # 2019-09-12 ## Volunteers wanted - We are looking for someone with access to an `arm/musl` system to help troubleshoot [#60297](https://github.com/rust-lang/rust/pull/60297) ## Backport nominations - Update LLVM submodule [#64317](https://github.com/rust-lang/rust/pull/64317) - Approved for beta backport - fix nounwind attribute logic [#63909](https://github.com/rust-lang/rust/pull/63909) - No conclusion reached yet. We'll revisit next week. - pprust: Do not print spaces before some tokens [#63897](https://github.com/rust-lang/rust/pull/63897) - Approved for beta backport # Working group sync ## [wg-polonius](https://rust-lang.github.io/compiler-team/working-groups/polonius/) - After a long hiatus, this working group is being rebooted with a focus on expanding [Polonius](https://github.com/rust-lang/polonius) coverage to include initialization checking and region subtyping in addition to borrow checking. - Work is also proceceeding on a book which will document the rules for Polonius. The hope is this will both make it easier to understand Polonius and also help make it easier for new contributors to get involved. - [@Albin Stjerna](https://github.com/albins) is also working on a master's thesis which overlaps with the Polonius work. - [@Aaron Weiss](https://github.com/aatxe) and [@nikomatsakis](https://github.com/nikomatsakis) realized that there maybe opportunities to make Polonius more precise. [Related video chat](https://www.youtube.com/watch?v=mAUGvNgZYtw&list=PL85XCvVPmGQitE2CBzf-gERSqeXo59NQG&index=4&t=0s) - [@lqd](https://github.com/lqd) has been working on a rustc compare mode which will check Polonius against the current borrow checker. [@Matthew Jasper](https://github.com/matthewjasper) and [@lqd](https://github.com/lqd) have made a number of fixes and cleanups so nearly all of the rustc tests pass under the Polonius compare-mode. - Some general performance work has been done but there's more to do especially around large constants. - Some vocabularly is also being decided on. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-09-12.20.2354818/near/175535951) ## [wg-rfc-2229](https://rust-lang.github.io/compiler-team/working-groups/rfc-2229/) - [RFC 2229](https://github.com/rust-lang/rfcs/blob/master/text/2229-capture-disjoint-fields.md) changes closures so they don't capture entire variables, but rather subpaths. - [@blitzerr](https://github.com/blitzerr) has been working on a refactoring related to how closure substitutions work. This is mostly done but it's hit some issues related to diagnostics and needs also needs to be rebased. - Work is ongoing. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-09-12.20.2354818/near/175536581) --- ### Minutes Triage Meeting 2019 09 19 (`content/minutes/triage-meeting/2019-09-19.md`) --- title: 2019.09.19 type: docs --- # 2019-09-19 ## Volunteers wanted - "Better error message when attempting to instantiate tuple structs with private fields" [#58017](https://github.com/rust-lang/rust/issues/58017) - Volunteer wanted to bisect this issue. ## Backport nominations - "fn ptr is structural match" [#64431](https://github.com/rust-lang/rust/pull/64431) - Accepted for beta backport - "fix nounwind attribute logic" [#63909](https://github.com/rust-lang/rust/pull/63909) - Declined for beta backport ## Working group sync ### [wg-self-profile](https://rust-lang.github.io/compiler-team/working-groups/self-profile/) Three main things being worked on: 1. Getting the "minimum viable product" done as planned [#58967](https://github.com/rust-lang/rust/issues/58967) 2. Improving the ergonomics of self-profiling - we want to collect use cases on [irlo](https://internals.rust-lang.org/t/compiler-profiling-survey/10969) and then try to come up with good, tooling assisted workflows for those use cases 3. Use self-profiling to implement a feature that allows to attribute compile time to specific parts of the source code - this feature is currently still in the brainstorming phase - comments welcome https://github.com/rust-lang/measureme/issues/51 [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-09-19.20.2354818/near/176105683) ### [wg-rls-2.0](https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/) - Chalk has been integrated, a number of performance problems have been fixed, and now it works great! - Macro by example and associated macro resolution work well enough to cover significant subset of the real world code - We added a simple hack to show compiler errors by just running cargo check - First win of librarification: rustc and rust-analyzer share the same lexer code! - After slowing down during August, they are starting the next sprint. The goal is to library-ify type-relating things: so, chalk + unification + a definition of Ty [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-09-19.20.2354818/near/176106397) --- ### Minutes Triage Meeting 2019 09 26 (`content/minutes/triage-meeting/2019-09-26.md`) --- title: 2019.09.26 type: docs --- # 2019-09-26 ## Volunteers wanted - Help wanted: proc-macro param attrs dropping first attrs in impl fns [#64682](https://github.com/rust-lang/rust/issues/64682) - Help wanted: error: internal compiler error: unexpected panic: inconsistent resolution for a macro [#64803](https://github.com/rust-lang/rust/issues/64803) ## Backport nominations - Fix #64744. Account for the Zero sub-pattern case. [#64748](https://github.com/rust-lang/rust/pull/64744) - Approved for beta backport - Rustdoc render async function re-export [#64599](https://github.com/rust-lang/rust/pull/64599) - Approved for beta backport ## Working group sync ### [wg-traits](https://rust-lang.github.io/compiler-team/working-groups/traits/) `wg-traits` is spinning back up and has a number of projects currently being worked on: - More Chalk work - Investigating lazy normalization - Enabling trait upcasts - Resolving `dyn Trait` coherence and well-formedness issues - Work is progressing to allow stabilization of the `!` type [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-09-26.20.2354818/near/176664817) --- ### Minutes Triage Meeting 2019 10 10 (`content/minutes/triage-meeting/2019-10-10.md`) --- title: 2019.10.10 type: docs --- # 2019-10-10 ## Announcements - @centril is splitting `libsyntax` into data and logic parts which will decrease the amount of code `librustc` depends on. - @nagisa a cross-platform version of stacker which will allow us to avoid stack overflows in rustc. - There is a compiler team design meeting scheduled for tomorrow (2019-10-11) to discuss some of @Zoxc's PRs. - @pnfelix is revising the code that handles structural match checking. - @nikomatsakis has a PR ([#65232](https://github.com/rust-lang/rust/issues/65232)) up which helps us get closer to lazy normalization. - `wg-traits` is going to start holding a weekly "office hours" video call to help answer questions and teach people about trait system internals. ## Volunteers wanted ## Backport nominations - Ensure that associated async fns have unique fresh param names [#65142](https://github.com/rust-lang/rust/pull/65142) - Approved for beta backport - Account for macro invocation in let mut $pat diagnostic. [#65123](https://github.com/rust-lang/rust/pull/65123) - Approved for beta backport - Fix the start/end byte positions in the compiler JSON output [#65074](https://github.com/rust-lang/rust/pull/65074) - Declined for beta backport - extract expected return type for async fn generators [#64999](https://github.com/rust-lang/rust/pull/64999) - Declined for beta backport ## Working group sync ### [wg-rustc-dev-guide](https://rust-lang.github.io/compiler-team/working-groups/rustc-dev-guide/) - `wg-rustc-dev-guide` has been working on transcribing videos from the [compiler lecture series](https://www.youtube.com/watch?v=elBxMRSNYr4&list=PL85XCvVPmGQhOL-J2Ng7qlPvDVOwYpGTN) into [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/) chapters. - Originally, individuals were assigned one or lectures to complete but that hasn't worked very well. - Recently, they're trying to work on one video at a time as a team with much better results. - There's [a PR](https://paper.dropbox.com/doc/Ty-lecture-summary--Almbjo_id6n8CKrOHlsTMG2dAg-4jFj9bVOLlW7uhIOWHITX) open for a new chapter based on the `ty` lecture. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-10.20.2354818/near/177816515) ### [wg-llvm](https://rust-lang.github.io/compiler-team/working-groups/llvm/) - rustc has upgraded to the LLVM 9 release; - Which allows us to replace some the emscripten stuff with LLVM’s toolchain. The less emscripten we have to deal with, the better! - As part of these upgrades we will likely end up dropping support for the super old LLVM 6, which in turn allows us to stop building the unnecessary Go & OCaml bindings to LLVM, which in turn helps rustc build times slightly. - People are also working on enabling use of the new pass manager, which might give us some tangible code quality improvements over the status quo. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-10.20.2354818/near/177817116) --- ### Minutes Triage Meeting 2019 10 17 (`content/minutes/triage-meeting/2019-10-17.md`) --- title: 2019.10.17 type: docs --- # 2017-10-17 ## Announcements - Design meeting on [debuginfo strategy](https://github.com/rust-lang/compiler-team/issues/186) tomorrow (2019-10-18) on Zulip. - The traits working group had a [design meeting](https://github.com/rust-lang/wg-traits/tree/master/minutes) yesterday on lazy normalization. - [@nikomatsakis] has been looking into lazy normalization specifically for constants and hopes to have some notes to share soon. - The LLVM ICE-breakers working group is nearly ready to go live. - [@spastorino] has nearly finished interning `Place` projections. [PR 1](https://github.com/rust-lang/rust/pull/65197), [PR2](https://github.com/rust-lang/rust/pull/65315) - [@centril] is continuing to work on [splitting `libsyntax` apart](https://github.com/rust-lang/rust/pull/65324) ## Volunteers wanted - Segfault compiling libc on armv7-unknown-linux-gnueabihf [#62896](https://github.com/rust-lang/rust/issues/62896) - Couldn't load codegen backend on windows-gnu [#61561](https://github.com/rust-lang/rust/issues/61561) ## Backport nominations - Add troubleshooting section to PGO chapter in rustc book [#65402](https://github.com/rust-lang/rust/pull/65402) - Approved for beta backport - Optimize try_expand_impl_trait_type [#65293](https://github.com/rust-lang/rust/pull/65293) - Approved for beta backport - Use precalculated dominators in explain_borrow [#65172](https://github.com/rust-lang/rust/pull/65172) - Approved for beta backport ## Working group sync ### [wg-mir-opt](https://rust-lang.github.io/compiler-team/working-groups/mir-opt/) - [@wesleywiser] Moved promoted MIR out of `mir::Body` [#63580](https://github.com/rust-lang/rust/pull/63580) - [@wesleywiser] Reimplemented the `ConstProp` optimization pass on top of the existing const eval code [#64419](https://github.com/rust-lang/rust/pull/64419) - [@spastorino] Converted `mir::Place` to no longer be a recursive data structure [#63420](https://github.com/rust-lang/rust/pull/63420) - There is ongoing work in both const prop and place refactorings. - We've figured out a plan for "weird" place projections like dereferences (virtual locals). [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-17.20.2354818/near/178389131) ### [wg-meta](https://rust-lang.github.io/compiler-team/working-groups/meta/) - The [Inside Rust](https://blog.rust-lang.org/inside-rust/index.html) blog has launched. - The [ICE-Breaker group](https://rustc-dev-guide.rust-lang.org/ice-breaker/about.html) has been formed! - The [LLVM ICE-Breaker group](https://rustc-dev-guide.rust-lang.org/ice-breaker/llvm.html) is also being formed. [Link to full conversation](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-17.20.2354818/near/178389266) [@nikomatsakis]: https://github.com/nikomatsakis [@spastorino]: https://github.com/spastorino [@centril]: https://github.com/centril [@wesleywiser]: https://github.com/wesleywiser --- ### Minutes Triage Meeting 2019 10 24 (`content/minutes/triage-meeting/2019-10-24.md`) --- title: 2019.10.24 type: docs --- # 2019-10-24 ## Announcments - [@simulacrum](https://github.com/Mark-Simulacrum) landed the rustc-dev split PR which decreases the size of the rustc-dev rustup component [#65474](https://github.com/rust-lang/rust/pull/65474) ## Backport nominations - Avoid ICE when adjusting bad self ty [#65755](https://github.com/rust-lang/rust/pull/65755) - Accepted for beta and stable backport - Avoid ICE when checking Destination of break inside a closure [#65518](https://github.com/rust-lang/rust/pull/65518) - Accepted for beta and stable backport - save-analysis: Nest tables when processing impl block definitions [#65511](https://github.com/rust-lang/rust/pull/65511) - Accepted for beta backport - save-analysis: Don't ICE when resolving qualified type paths in struct members [#65353](https://github.com/rust-lang/rust/pull/65353) - Accepted for beta backport ## Working group sync ### [wg-nll](https://rust-lang.github.io/compiler-team/working-groups/nll/) - Rust 1.40 (current nightly) will be the first stable release without the HIR borrow checker. This means Non Lexical Lifetimes will be available on Rust 2015. - At this point, wg-nll has completed its purpose and will be disbanded. - wg-polonius is still going strong though! [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-24.20.2354818/near/178960111) ### [wg-parallel-rustc](https://rust-lang.github.io/compiler-team/working-groups/parallel-rustc/) - Work is proceeding slowly but steadily. There are regular triage meetings every Monday on the compiler calendar. - The current goal is to refactor/audit compiler locks and other parts of the parallel query system and to investigate improving performance. - The current MVP is to do high-level parallelization in a few critical places such as typechecking & linting. - Currently, we're not seeing the speedups we want from parallelization but work is ongoing to remove locking and improve the jobserver integration. - [Video recording of last meeting](https://youtu.be/lVjW0Nw8N_g) [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-24.20.2354818/near/178960379) --- ### Minutes Triage Meeting 2019 10 31 (`content/minutes/triage-meeting/2019-10-31.md`) --- title: 2019.10.31 type: docs --- # 2019-10-31 ## Announcments Rust 1.39 ships on Thursday! ## Backport nominations - "save-analysis: Account for async desugaring in async fn return types" [#65936](https://github.com/rust-lang/rust/pull/65936) - Accepted for beta backport - "resolve: Turn the "non-empty glob must import something" error into a lint" [#65539](https://github.com/rust-lang/rust/pull/65539) - Accepted for beta backport ## Working group sync ### [wg-pgo](https://rust-lang.github.io/compiler-team/working-groups/pgo/) - PGO is available in the stable compiler. Docs are in the rustc-dev-guide and the rustc-book - Unfortunately we don't observe significant performance gains from applying it (except for tiny synthetic test cases). - [@michaelwoerister] asked for people to try PGO on irlo but haven't gotten a lot of feedback. - There is one interesting theory that Rust doesn't profit as much as C++ because it defaults to having fewer compilation units and thus can make better inlining decisions in the non-PGO case. - The working group will probably wind down as [@michaelwoerister] don't have time to pursue further and there are no actual known issues in the implementation. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-31.20.2354818/near/179539153) ### [wg-pipelining](https://rust-lang.github.io/compiler-team/working-groups/pipelining/) - Pipelining support has shipped in Rust 1.38. - The working group is winding down. [Link to full discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202019-10-31.20.2354818/near/179539371) [@michaelwoerister]: https://github.com/michaelwoerister --- ### Minutes Triage Meeting 2019 11 07 (`content/minutes/triage-meeting/2019-11-07.md`) --- title: 2019.11.07 type: docs --- # 2019-11-07 ## Announcments - [@pnkfelix] is moving to the US and will be working in the Eastern timezone. - [@wesleywiser] has been working on the constant propagation pass and wants to [turn it on][const_prop_on] for debug & release builds to improve compilation time. - Rust 1.39 has shipped with `async`/`await` support and other goodies. ## Backport nominations - Do not ICE with a precision flag in formatting str and no format arguments [#66093](https://github.com/rust-lang/rust/pull/66093) - Approved for beta & stable backport. ## Working group sync ### [wg-polonius] We ran out of time this week to have a check-in from this working group. ### [wg-rfc-2229] This working group is currently on a pause. [@pnkfelix]: https://github.com/pnkfelix [@wesleywiser]: https://github.com/wesleywiser [const_prop_on]: https://github.com/rust-lang/rust/pull/66074 [wg-polonius]: https://rust-lang.github.io/compiler-team/working-groups/polonius/ [wg-rfc-2229]: https://rust-lang.github.io/compiler-team/working-groups/rfc-2229/ --- ### Minutes Triage Meeting 2019 11 14 (`content/minutes/triage-meeting/2019-11-14.md`) --- title: 2019.11.14 type: docs --- # 2019-11-14 ## Announcements - Request for assistance: "Rustc panics (NoSolution): could not prove Binder(projection soup)" [#65581](https://github.com/rust-lang/rust/issues/65581) - Request for assistance: "Rust 1.38 regressions weren't fully triaged" [#65577](https://github.com/rust-lang/rust/issues/655577) - Request for assistance: "Miscompilation with target-cpu=znver1 (AMD Ryzen 1000/2000 series) on Windows + LLVM 9." [#63959](https://github.com/rust-lang/rust/issues/63959) - [@cjgillot] replaced a lot of TypeFoldable impls with a derive [#66384](https://github.com/rust-lang/rust/pull/66384) - The Infra team has finished evaluating GitHub Actions and we're switching! - This will have a signficant, positive impact on CI build time. - [@centril] is fixing useless `` spans [#66364](https://github.com/rust-lang/rust/pull/66364) ## Backport nominations - "Fix two OOM issues related to ConstProp" [#66394](https://github.com/rust-lang/rust/pulls/66394) - Approved for beta backport - "Do not ICE on trait aliases with missing obligations" [#66392](https://github.com/rust-lang/rust/pulls/66392) - Approved for beta backport - "Do not ICE in if without else in async fn" [#66391](https://github.com/rust-lang/rust/pulls/66391) - Approved for beta backport - "Fix ICE when trying to suggest Type<> instead of Type()" [#66390](https://github.com/rust-lang/rust/pull/66390) - Approved for beta backport - "Do not ICE on recovery from unmet associated type bound obligation" [#66388](https://github.com/rust-lang/rust/pull/66388) - Approved for beta backport - "find_deprecation: deprecation attr may be ill-formed meta." [#66381](https://github.com/rust-lang/rust/pull/66381) - Approved for beta backport - "parser: don't use unreachable!() in fn unexpected." [#66361](https://github.com/rust-lang/rust/pull/66361) - Approved for beta backport - "Undo an assert causing an ICE until we fix the underlying problem" [#66250](https://github.com/rust-lang/rust/pull/66250) - Approved for beta backport - "Do not ICE with a precision flag in formatting str and no format arguments" [#66093](https://github.com/rust-lang/rust/pull/66093) - Approved for stable & beta backport ## Working group sync ### [wg-polonius](https://rust-lang.github.io/compiler-team/working-groups/polonius/) - Made a lot of progress on the completeness goals with move/initialization errors and subset errors both getting close to completion. - Fixed the last failure in the rustc test suite. - There are still the same 2 OOMs as last time, we haven't had much time to look at those yet. - Made diagnostics output match NLL in a lot more cases. - Did some cleanup in our terminology by picking better names for our atoms hopefully making it clearer in the process, and more work is planned here. - "origin" instead of "region" - "path" instead of "MovePath" - There is a [polonius book](https://rust-lang.github.io/polonius/) now! It's sparse at the moment but more documentation work is in-flight and planned. - The exploration and prototype on the rules offering more flow-sensitive precision for the analysis has also progressed a lot. - There's also been some refactoring, and quite a bit of work on performance. Since the latter can step on the other work and vice-versa, we decided to focus on completeness first, and then after that has been achieved, re-adapt and land the optimization work. - [@nikomatsakis] did a presentation on Polonius at RustBelt Rust. [Slides](https://nikomatsakis.github.io/rust-belt-rust-2019/) - [@albins] has finished their master's thesis and is currently rewriting most of the [draft](https://rust-lang.zulipchat.com/user_uploads/4715/ufu5BGNrkzVbV8FtkK3Tco6M/Albins-Thesis-draft-version.pdf). - We hope to have a "polonius work week" at the end of November to push the in-progress work over the finish line together. ### [wg-self-profile](https://rust-lang.github.io/compiler-team/working-groups/self-profile/) - We've nearly completed our long standing MVP goal! - [@simulacrum] has done some nice work to polish the integration with perf.rlo - We've added tracking for all the events we're aware of that should be traced with the exception of trait selection. - We could really use some input as to what would be helpful to track! - [@mw] has been working on some changes to the binary format we record events in. - The new format is more compact so results in a smaller trace file and hopefully less runtime overhead. - The new format is also more amenable to recording query keys, which is a highly requested feature. - [@wesleywiser] has added some crate level docs to make getting into the code easier. - [@wesleywiser] also added code to record process id, start time, and arguments to the trace file which we've started using. - [@andjo403] has been a roll with a lot of great PRs! - We now have a dedicated tool for generating flamegraphs directly so you don't have to use the Perl scripts anymore. - Some internal refactoring that makes adding new tools easier. - Lots of work on the Chromium dev tools exporter: - New option to collapse disjoint threads so it's a little more manageable - New option to filter out small events under a configurable threshold (necessary for very large compilations) - :tada: :tada: You can now have multiple crate compilations in the same export file. This is similar to what cargo build -Z timings can do but much more detailed. ### [wg-rls-2.0](https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/) - Work is procedding on splitting core of rust-analyzer into crates. - Find usages is implemented. - Macro expansion now can map source ranges to expanded ranges, so goto def correctly goes "inside" macro call. - More chalk an type inference work, specifically, support for closures. - There's ongoing discussion about the general planning about rustc, rls, and rust-analyzer. [@cjgillot]: https://github.com/cjgillot [@centril]: https://github.com/centril [@nikomatsakis]: https://github.com/nikomatsakis [@albins]: https://github.com/albins [@mw]: https://github.com/michaelwoerister [@wesleywiser]: https://github.com/wesleywiser [@andjo403]: https://github.com/andjo403 --- ### Minutes Triage Meeting 2019 11 21 (`content/minutes/triage-meeting/2019-11-21.md`) --- title: 2019.11.21 type: docs --- # 2019-11-21 ## Announcements - perf.rust-lang.org is switching to a new benchmarking server so all of the old data is being removed to avoid skewed comparisons. - The constant propagation MIR optimization pass is [on by default][const_prop_on] which provides some improvements to debug and release compile times. - [@pnkfelix] wrote a blog post about [minimizing rustc bugs][minimizing_rustc_bugs]. ## Backport nominations - "Do not ICE on trait aliases with missing obligations” [#66392] - Accepted for stable backport - "Fix ICE when trying to suggest Type<> instead of Type()" [#66390] - Accepted for stable backport - “Do not ICE on recovery from unmet associated type bound obligation” [#66388] - Accepted for stable backport - “find_deprecation: deprecation attr may be ill-formed meta.” [#66381] - Accepted for stable backport - “parser: don’t use unreachable!() in fn unexpected.” [#66361] - Accepted for stable backport ## Working group sync ### [wg-traits] - [@Alexander Regueiro] is very close to landing support for trait object upcasts. - Chalk is being refactored with the goal of revamping how the rustc integration works so they share a lot more code. - [@Jack Huey] has been fixing the handling of coinduction logic and generally refactoring the chalk engine. - Work has been proceeding to fix a soundess hole related to `dyn Trait` ([#57893]) [@Alexander Regueiro]: https://github.com/alexreg [@Jack Huey]: https://github.com/jackh726 [@pnkfelix]: https://github.com/pnkfelix [#57893]: https://github.com/rust-lang/rust/issues/57893 [#66361]: https://github.com/rust-lang/rust/pull/66361 [#66381]: https://github.com/rust-lang/rust/pull/66381 [#66388]: https://github.com/rust-lang/rust/pull/66388 [#66390]: https://github.com/rust-lang/rust/pull/66390 [#66392]: https://github.com/rust-lang/rust/pull/66392 [const_prop_on]: https://github.com/rust-lang/rust/pull/66074 [minimizing_rustc_bugs]: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns [wg-traits]: https://rust-lang.github.io/compiler-team/working-groups/traits --- ### Minutes Triage Meeting 2019 11 28 (`content/minutes/triage-meeting/2019-11-28.md`) --- title: 2019.11.28 type: docs --- # 2019-11-28 ## Announcements - perf.rust-lang.org has been fully migrated to the new server for benchmarking. - GitHub Actions is now running both Windows and Linux workloads! ## Backport nominations - "Handle non_exhaustive in borrow checking" [#66722] - Accepted for beta backport - "Fix some issues with attributes on unnamed fields" [#66669] - Accepted for beta backport ## Working group sync ### [wg-diagnostics] - Work is proceeding slowly on the [out-of-tree diagnostic rendering][diag_rendering]. [#66669]: https://github.com/rust-lang/rust/pull/66669 [#66722]: https://github.com/rust-lang/rust/pull/66722 [diag_rendering]: https://github.com/rust-lang/annotate-snippets-rs/ [wg-diagnostics]: https://rust-lang.github.io/compiler-team/working-groups/diagnostics/ --- ### Minutes Triage Meeting 2019 12 05 (`content/minutes/triage-meeting/2019-12-05.md`) --- title: 2019.12.05 type: docs --- # 2019-12-05 ## Announcements - [@centril] is working on a major refactoring of the expression, statement, and item parsers in librustc_parse - [@eddyb] landed [#56231] which unblocks optimizing MIR while preserving debuginfo for variables. ## Backport nominations - "E0023: handle expected != tuple pattern type" [#67044] - Approved for beta backport - "Fix some issues with attributes on unnamed fields" [#66669] - Approved for beta & stable backport - "Do not ICE in if without else in async fn" [#66391] - Approved for stable backport ## Working group sync ### [wg-rustc-dev-guide] Accomplished: - We have a [chapter about Salsa][salsa_chapter], it was summarized from [this lecture][lecture_1]. - We have a [PR for the ty chapter][ty_chapter], it summarizes [this lecture][lecture_2]. - We had a [planning meeting][meeting], where we come up with a [document with ideas and next steps][doc] for the rustc-dev-guide. We've basically defined kind of a roadmap and a way to work towards those goals. Next-steps: - Start writing an Overview chapter - Organize a lecture about codegen mir -> llvm IR ([@nagisa], maybe?) - Organize a lecture about LLVM ([@alexcrichton], maybe?) - Organize a lecture about monomorphization/type memory layout ([@oli-obk], maybe?) [#66391]: https://github.com/rust-lang/rust/pull/66391 [#66669]: https://github.com/rust-lang/rust/pull/66669 [#67044]: https://github.com/rust-lang/rust/pull/67044 [@alexcrichton]: https://github.com/alexcrichton [@centril]: https://github.com/centril [@eddyb]: https://github.com/eddyb [@nagisa]: https://github.com/nagisa [@oli-obk]: https://github.com/oli-obk [doc]: https://hackmd.io/iamkyR_QTdSIdGjYQX_XjQ [lecture_1]: https://www.youtube.com/watch?v=_muY4HjSqVw [lecture_2]: https://www.youtube.com/watch?v=c01TsOsr3-c [meeting]: https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-rustc-dev-guide/topic/planning.20meeting [salsa_chapter]: https://github.com/rust-lang/rustc-dev-guide/pull/529 [ty_chapter]: https://github.com/rust-lang/rustc-dev-guide/pull/530 [wg-rustc-dev-guide]: https://rust-lang.github.io/compiler-team/working-groups/rustc-dev-guide --- ### Minutes Triage Meeting 2019 12 12 (`content/minutes/triage-meeting/2019-12-12.md`) --- title: 2019.12.12 type: docs --- # 2019-12-12 ## Announcements - [@pnkfelix] posted an RFC about future-incompat lints [RFC 2834] - [@eddyb] landed some additional caching for trait selection which gives some nice speedups [#66821] - Const eval now has support for `if`/`match` and a PR for `loop`/`while` is open. - [@eddyb] is resurrecting their SROA MIR optimization [#48300] ## Backport nominations - resolve: Always resolve visibilities on impl items [#67236] - Approved for beta backport - resolve: Resolve visibilities on fields with non-builtin attributes [#67106] - Approved for beta backport ## Working group sync ### [wg-meta] - Work has generally slowed down since the launch of the ICE breakers group. - Some planning for a new "reducer" group has begun. ### [wg-mir-opt] - MIR does not know about static items anymore. Instead we just have a constant whose value is `&YOUR_STATIC`, `&raw mut YOUR_MUT_STATIC` or `&raw YOUR_EXTERN_STATIC`. This simplifies a lot of logic in the MIR and will (together with the next bullet point) allow `PlaceBase` to just be a `Local` (so a u32 index for a local to be accessed). [#66587] - [@spastorino] is about to finish a PR that removes promoteds from the list of things that are `Place`s in MIR - `mir::Body` does not contain interior mutability components anymore. It used to have a cache of some information on the MIR CFG that could get cleared and reinitialized as required. This is abstracted away in the `BodyCache` type. - Promoteds inside constants and statics are now actually separated from their constant's `mir::Body` instead of having a scheme around removing `StorageDead` statements [#66642] - Cross crate inlining now preserves debug info [#66789] - There is a new MIR optimization eliminating basic blocks that are unreachable because they are match arms of uninhabited variants [#65694] - There is a new MIR optimization to work around the problem that LLVM can't figure out trivial match arms like `Ok(x) => Ok(x)` [#66282] - The const prop optimization now runs on all builds (even debug builds) because this gives quite some nice build time improvements [#66074] - We had a mir-opt room at RustFest, which was a total success and people loved it. [@eddyb]: https://github.com/eddyb [@pnkfelix]: https://github.com/pnkfelix [@spastorino]: https://github.com/spastorino [#48300]: https://github.com/rust-lang/rust/pull/48300 [#65694]: https://github.com/rust-lang/rust/pull/65694 [#66074]: https://github.com/rust-lang/rust/pull/66074 [#66282]: https://github.com/rust-lang/rust/pull/66282 [#66587]: https://github.com/rust-lang/rust/pull/66587 [#66642]: https://github.com/rust-lang/rust/pull/66642 [#66789]: https://github.com/rust-lang/rust/pull/66789 [#66821]: https://github.com/rust-lang/rust/pull/66821 [#67106]: https://github.com/rust-lang/rust/pull/67106 [#67236]: https://github.com/rust-lang/rust/pull/67236 [RFC 2834]: https://github.com/rust-lang/rfcs/pull/2834 [wg-meta]: https://rust-lang.github.io/compiler-team/working-groups/meta/ [wg-mir-opt]: https://rust-lang.github.io/compiler-team/working-groups/mir-opt/ --- ### Minutes Triage Meeting 2019 12 19 (`content/minutes/triage-meeting/2019-12-19.md`) --- title: 2019.12.19 type: docs --- # 2019-12-19 ## Announcements - [@pnkfelix] has moved back to the USA - There will be a new [Rust release] by end-of-day - [@michaelwoerister] has a PR up that adds support for recording query-keys during a `-Z self-profile` session [#67397] - [@matthewjasper] and [@wesleywiser] have been asked to join the compiler team as full members and both have accepted - [@centril] is working on a stabilization report for sub-slice patterns ## Backport nominations - Don't suppress move errors for union fields [#67314] - Deferred until next week - Do not ICE on unnamed future [#67289] - Accepted for beta backport ## Working group sync ### [wg-parallel-rustc] - Posted an [Internals thread] to gather feedback from users trying out the parallel compiler build - [@joshtriplett] has done some profiling on a 72 core machine which may have revealed a deadlock and some scalability issues, which they'll be looking into - The current overall plan is to evaluate the performance and other reports on the internals thread, and then likely move forward on shipping the parallel compiler early in the new year with the default thread count still capped at 4 [@centril]: https://github.com/centril [@joshtriplett]: https://github.com/joshtriplett [@matthewjasper]: https://github.com/matthewjasper [@michaelwoerister]: https://github.com/michaelwoerister [@pnkfelix]: https://github.com/pnkfelix [@wesleywiser]: https://github.com/wesleywiser [#67289]: https://github.com/rust-lang/rust/pull/67289 [#67314]: https://github.com/rust-lang/rust/pull/67314 [#67397]: https://github.com/rust-lang/rust/pull/67397 [Internals thread]: https://internals.rust-lang.org/t/help-test-parallel-rustc/11503 [Rust release]: https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html [wg-parallel-rustc]: https://rust-lang.github.io/compiler-team/working-groups/parallel-rustc/ --- ### Minutes Triage Meeting 2020 01 02 (`content/minutes/triage-meeting/2020-01-02.md`) --- title: 2020.01.02 type: docs --- # 2020-01-02 ## Announcements - Happy new year! - [@centril] has a PR to extract `rustc_hir` from `rustc` [#67803] - [@centril] and [@matthewjasper] have written a stabilization report for `slice_patterns` [#67712] ## Backport nominations - Do not ICE on lifetime error involving closures [#67687] - Approved for beta backport - Treat extern statics just like statics in the “const pointer to static” representation [#67630] - Deferred until next week - Use the correct type for static qualifs [#67621] - Approved for beta backport - Don’t suppress move errors for union fields [#67314] - Approved for beta backport - Do not ICE on unnamed future [#67289] - Approved for beta backport - Do not ICE on lifetime error involving closures [#67687] - Stable backport declined ## Working group sync ### [wg-rustc-dev-guide] - The new chapter "Intro to `ty`" is nearly ready to merge! [#67687]: https://github.com/rust-lang/rust/pull/67687 [#67289]: https://github.com/rust-lang/rust/pull/67289 [#67314]: https://github.com/rust-lang/rust/pull/67314 [#67621]: https://github.com/rust-lang/rust/pull/67621 [#67630]: https://github.com/rust-lang/rust/pull/67630 [#67712]: https://github.com/rust-lang/rust/pull/67712 [#67803]: https://github.com/rust-lang/rust/pull/67803 [@centril]: https://github.com/centril [@matthewjasper]: https://github.com/matthewjasper [wg-rustc-dev-guide]: https://rust-lang.github.io/compiler-team/working-groups/rustc-dev-guide/ --- ### Minutes Triage Meeting 2020 01 09 (`content/minutes/triage-meeting/2020-01-09.md`) --- title: 2020.01.09 type: docs --- # 2020-01-09 ## Announcements - Lots of activity happening on const generics & lazy normalization - For example, [#67890] by [@benlewis] ## Beta nominations - Do not ICE on lifetime error involving closures [#67687] - Approved for stable & beta backport - Treat extern statics just like statics in the "const pointer to static" representation [#67630] - Approved for beta backport - Use the correct type for static qualifs [#67621] - Approved for beta backport - Don't suppress move errors for union fields [#67314] - Approved for beta backport ## Working group sync ### [wg-meta] - Work is staring on forming a new "bisection ICE-breaker" group and a process for large compiler changes ### [wg-mir-opt] - There's been [some discussion] on MIR 2.0 - [#67000] will finally make mir::Place not be able to point to statics or promoteds anymore but just locals - [#67662] and [#67333] get us closer to bootstrapping rustc with mir inlining - Const prop can now propagate into the rhs of assignments to user defined variables [#67130] [#67000]: https://github.com/rust-lang/rust/pulls/67000 [#67130]: https://github.com/rust-lang/rust/pulls/67130 [#67314]: https://github.com/rust-lang/rust/pulls/67314 [#67333]: https://github.com/rust-lang/rust/pulls/67333 [#67621]: https://github.com/rust-lang/rust/pulls/67621 [#67630]: https://github.com/rust-lang/rust/pulls/67630 [#67662]: https://github.com/rust-lang/rust/pulls/67662 [#67687]: https://github.com/rust-lang/rust/pulls/67687 [#67890]: https://github.com/rust-lang/rust/pulls/67890 [@benlewis]: https://github.com/skinny121 [some discussion]: https://hackmd.io/aQ8y79EfS72VCUoEmzLQpg [wg-meta]: https://rust-lang.github.io/compiler-team/working-groups/meta/ [wg-mir-opt]: https://rust-lang.github.io/compiler-team/working-groups/mir-opt/ --- ### Minutes Triage Meeting 2020 01 23 (`content/minutes/triage-meeting/2020-01-23.md`) --- title: 2020.01.23 type: docs --- # 2020-01-23 ## Announcements - No compiler team design meeting tomorrow, it has been rescheduled for Feb 7. We'll be discussing ["parser library-ification"][parser]. - The next Rust release is scheduled for Jan 30 (one week away). The tools "no breakage week" started yesterday in preperation for the release. ## Backport nominations - Do not ICE on malformed suggestion spans [#68256] - Approved for beta backport. - Revert parts of #66405 [#67471] - Approved for beta backport. [#67471]: https://github.com/rust-lang/rust/pull/67471 [#68256]: https://github.com/rust-lang/rust/pull/68256 [parser]: https://github.com/rust-lang/compiler-team/issues/237 --- ### Minutes Triage Meeting 2020 02 06 (`content/minutes/triage-meeting/2020-02-06.md`) --- title: 2020.02.06 type: docs --- # 2020-02-06 ## Announcements - There is a design meeting this Friday (2020-02-07) on [parser-librarification]. - [@davidtwco] has made progress on the polymorphization effort and has posted a [status update][polymorph_update]. - [@mw] has posted a major change proposal to make [incremental compilation respect the `-Ccodegen-units` setting][mw_change]. - Cargo report future-incompat [rfc#2834] is on track to get an FCP merge request from the cargo team in the near future. ## Backport nominations - Correct ICE caused by macros generating invalid spans [#68611] - Deferred until next week. - Do not ICE on multipart suggestions touching multiple files" [#68530] - Approved for beta backport. - Resolve long compile times when evaluating always valid constants [#67667] - Approved for stable backport. ## Working group sync ### [wg-rls-2.0] - The Chalk dependency has been updated which dramatically reduced crashes. - `cargo check` handling has been moved ino the server so all editors not just VS Code benefit. - [@matklad] and [@nikomatsakis] have been working on an RFC to merge RLS and Rust Analyzer officially. - Work is proceeding on "production readiness". - Binary releases are available on the project's GitHub page. - Planning to publish to VS Code extension marketplace "soon". ### [wg-self-profile] - The ["Minimum Viable Product"][sp_mvp] has been completed! - Self-profling is enabled for all perf.rust-lang.org runs and we automatically publish the data. ([Example][sp_example]) - [@mw] implemented query-key recording so queries can now be attributed to individual query invocations. - The [`crox`] utility, which generates Chromium profiler compatible trace data, can now generate profiles for entire Cargo invocations via the `--dir` flag. - This allows inspecting various rustc processes and their individual threads on a common timeline with full query data. - Quite a few people have tried `-Zself-profile` and have said they found it very useful! [#67667]: https://github.com/rust-lang/rust/pull/67667 [#68530]: https://github.com/rust-lang/rust/pull/68530 [#68611]: https://github.com/rust-lang/rust/pull/68611 [@davidtwco]: https://github.com/davidtwco [@matklad]: https://github.com/matklad [@mw]: https://github.com/michaelwoerister [@nikomatsakis]: https://github.com/nikomatsakis [`crox`]: https://github.com/rust-lang/measureme/tree/master/crox [mw_change]: https://github.com/rust-lang/compiler-team/issues/245 [parser-librarification]: https://github.com/rust-lang/compiler-team/issues/237 [polymorph_update]: https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/progress.20updates/near/187461928 [rfc#2834]: https://github.com/rust-lang/rfcs/issues/2834 [sp_example]: https://perf.rust-lang.org/detailed-query.html?commit=3761dcd3467441f78939ccb3b341b03b6a7558d7&base_commit=ac2f3fa41ac5ae8425b959f955bb7433b7c57aea&benchmark=await-call-tree-debug&run_name=clean [sp_mvp]: https://github.com/rust-lang/rust/issues/58967 [wg-rls-2.0]: https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/ [wg-self-profile]: https://rust-lang.github.io/compiler-team/working-groups/self-profile/ --- ### Minutes Triage Meeting 2020 02 13 (`content/minutes/triage-meeting/2020-02-13.md`) --- title: 2020.02.13 type: docs --- # 2020-02-13 ## Backport nominations - Correct ICE caused by macros generating invalid spans [#68611] - Approved for stable & beta backport - Fix extra subslice lowering [#69128] - Approved for beta backport ## Working group sync ### [wg-polymorphization] [@davidtwco] writes: > Since this is the first update to the compiler team meeting, this working group is my work for my master's thesis - it aims to implement an analysis to detect when functions could remain polymorphic during code generation. Hopefully this will reduce the amount of LLVM IR generated and improve compilation times. > So far, I've got a basic analysis working and I've got it integrated into the compiler such that a codegen-unit test that I've written pass with the analysis turned on and working. For the last couple months, I've been working on getting the compiler to bootstrap with the analysis turned on, and fighting ICEs to do so. > I've not been able to spend much time on it recently due to other university/work drains on my time, but progress should pick up soon. ### [wg-traits] - Planning is beginning to do a new set of "sprints". - The current goal is to implement some of the ideas learned from Chalk into rustc and make it able to support GATs etc while still working on Chalk with the goal of eventual rustc integration. - We want to start getting value out of the Chalk ideas now rather than waiting until it can be fully integrated with rustc. [#68611]: https://github.com/rust-lang/rust/pull/68611 [#69128]: https://github.com/rust-lang/rust/pull/69128 [@davidtwco]: https://github.com/davidtwco [wg-polymorphization]: https://rust-lang.github.io/compiler-team/working-groups/polymorphization/ [wg-traits]: https://rust-lang.github.io/compiler-team/working-groups/traits/ --- ### Minutes Triage Meeting 2020 02 20 (`content/minutes/triage-meeting/2020-02-20.md`) --- title: 2020.02.20 type: docs --- # 2020-02-20 ## Announcements - On Feb 28th we will discuss our triage procedures and how we can make them more efficient. See [rust-lang/compiler-team#247] for more details. - On Mar 6th, we will discuss plans to extract rustc's representation of types and trait solving into a standalone library. See [rust-lang/compiler-team#234] for more details. - Please review the new [rollup guidance] if you haven't yet. - Triagebot now has [notification functionality] ## Backport nominations - Revert "Remove checked_add in Layout::repeat" [#69241] - Approved for stable and beta backport - Do not ICE when encountering yield inside async block [#69175] - Approved for stable & beta backport - Account for bounds and asociated items when denying _ [#69148] - Backport declined - Make conflicting_repr_hints a deny-by-default c-future-compat lint [#68586] - Approved for beta backport - Fix MIR typeck soundness holes [#69145] - Approved for stable backport ## Working group sync We ran out of time due to a large number of issues to triage and the related discussion. [#68586]: https://github.com/rust-lang/rust/pull/68586 [#69145]: https://github.com/rust-lang/rust/pull/69145 [#69148]: https://github.com/rust-lang/rust/pull/69148 [#69175]: https://github.com/rust-lang/rust/pull/69175 [#69241]: https://github.com/rust-lang/rust/pull/69241 [rust-lang/compiler-team#234]: https://github.com/rust-lang/compiler-team/issues/234 [rust-lang/compiler-team#247]: https://github.com/rust-lang/compiler-team/issues/247 [rollup guidance]: https://internals.rust-lang.org/t/rollup-never-always-guidance/11827 [notification functionality]: https://internals.rust-lang.org/t/triagebot-notifications/11857 --- ### Minutes Triage Meeting 2025 Q3 T Compiler P High Issue Review Pre Triage (`content/minutes/triage-meeting/2025 Q3 T-compiler P-high Issue Review Pre-triage.md`) # 2025 Q3 T-compiler P-high Issue Review Pre-triage *Issues snapshot collected on 2025-07-17T12:25:42.073405408Z* ## P-high missing team label [P-high issues without team label](https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AP-high%20-label%3AT-cargo%20-label%3AT-community%20-label%3AT-compiler%20-label%3AT-core%20-label%3AT-crates-io%20-label%3AT-dev-tools%20-label%3AT-docs-rs%20-label%3AT-infra%20-label%3AT-libs%20-label%3AT-libs-api%20-label%3AT-release%20-label%3AT-release%20-label%3AT-rustdoc%20-label%3AT-style%20-label%3AT-types%20-label%3AT-lang%20-label%3AT-leadership-council) **Did not find P-high issues without a team label** ## P-high T-compiler issues missing owner (no WG and no assignee) [P-high issues with no owner](https://github.com/rust-lang/rust/issues?q=is%3Aissue%20is%3Aopen%20label%3AT-compiler%20label%3AP-high%20-label%3Awg-debugging%20-label%3AWG-embedded%20-label%3AWG-diagnostics%20-label%3AWG-async%20-label%3AWG-incr-comp%20no%3Aassignee%20sort%3Acreated-asc%20-label%3AI-types-nominated%20-label%3AI-lang-nominated%20-label%3AI-compiler-nominated%20-label%3AT-types%20-label%3AWG-llvm) ### #57893: Coherence can be bypassed by an indirect impl for a trait object Link: Creation date: 2019-01-25 Labels: `A-dyn-trait`, `A-trait-system`, `C-bug`, `I-ICE`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-types` Author: `arielb1` Working groups: Assignees: Notes: Still open issue but seems under T-types purview (starting from [comment](https://github.com/rust-lang/rust/issues/57893#issuecomment-1883989528)) and relevant [rollup commit](https://github.com/matthiaskrgr/rust/commit/69b13e4cabac3dcfa6a503e71781cc8fc3e86030) **TODO** ### #84366: 'static closures/FnDefs/futures with non-'static return type are unsound Link: Creation date: 2021-04-20 Labels: `A-associated-items`, `A-async-await`, `A-closures`, `A-lifetimes`, `A-trait-system`, `A-type-system`, `AsyncAwait-Triaged`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-types` Author: `steffahn` Working groups: Assignees: Notes: Still reproduces (see last [comment](https://github.com/rust-lang/rust/issues/84366#issuecomment-2831858257)). Also much newer related issue #141713 **TODO** ### #84591: HRTB on subtrait unsoundly provides HTRB on supertrait with weaker implied bounds Link: Creation date: 2021-04-26 Labels: `A-higher-ranked`, `A-implied-bounds`, `A-lifetimes`, `A-trait-system`, `A-type-system`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-types` Author: `steffahn` Working groups: Assignees: Notes: Mentioned in [#129005](https://github.com/rust-lang/rust/issues/129005#issue-2461029365) as known bug **TODO** ### #85099: A `Pin` unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>` Link: Creation date: 2021-05-09 Labels: `A-pin`, `C-bug`, `I-unsound`, `P-high`, `S-bug-has-test`, `T-compiler`, `T-lang`, `T-libs-api`, `T-types` Author: `steffahn` Working groups: Assignees: Notes: Seems not actively being worked on? **TODO** ### #103762: Broken compilation with `&(dyn Trait + '_)` Link: Creation date: 2022-10-30 Labels: `A-lifetimes`, `A-resolve`, `C-bug`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `Cerber-Ursi` Working groups: Assignees: Notes: Attempted a fix in #104272 but author abandoned the effort **TODO** ### #113104: Linking error on Rust 1.70 aarch64-unknown-linux-musl toolchain Link: Creation date: 2023-06-27 Labels: `A-linkage`, `C-bug`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `geauxvirtual` Working groups: Assignees: Notes: Will it change anything when we upgrade to musl 1.25 (MCP [rust#887](https://github.com/rust-lang/compiler-team/issues/887))? **TODO** ### #114838: CI accepted doctests that do not build (due to missing feature gates) Link: Creation date: 2023-08-15 Labels: `A-stability`, `C-bug`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Notes: This specific issue seems was fixed by #114837 (the play.r-l.org link now compiles). The general issue ("Why did CI accept a doctest that does not build?") maybe fixed as well in #97301 **TODO** ### #114858: ICE: unexpected initial operand type. Link: Creation date: 2023-08-15 Labels: `C-bug`, `F-impl_trait_in_assoc_type`, `I-ICE`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `fakeshadow` Working groups: Assignees: Notes: related to #57893 (above in this list), see [comment](https://github.com/rust-lang/rust/issues/57893#issuecomment-2621456777). **TODO** ### #115216: OOM/surprising memory consumption with Rust 1.72 Link: Creation date: 2023-08-25 Labels: `A-LLVM`, `C-bug`, `I-compilemem`, `O-wasm`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `silicology1` Working groups: Assignees: Notes: Last [comment](https://github.com/rust-lang/rust/issues/115216#issuecomment-2141479465) points to open LLVM issue [llvm-project#44793](https://github.com/llvm/llvm-project/issues/47793). Given the it affects the WASM tier 2 target, maybe downgrade? **TODO** ### #115336: `extern "C" fn` on sparc64 targets does not respect repr(transparent) Link: Creation date: 2023-08-29 Labels: `A-ABI`, `A-FFI`, `I-unsound`, `O-SPARC`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Notes: SPARC platform, maybe downgrade? PR fixing it #142680 waiting on review **TODO** ### #115465: Multiple nested loops taking very long to compile with CPU extensions Link: Creation date: 2023-09-02 Labels: `A-LLVM`, `C-bug`, `I-compiletime`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `Ben-Lichtman` Working groups: Assignees: Notes: Tried compiling the Godbolt repro with 1.88 and compiles pretty fast. Probably the LLVM issue (in [comment](https://github.com/rust-lang/rust/issues/115465#issuecomment-1711627094)) was solved? **TODO** ### #116344: The ABI of float types can be changed by `-Ctarget-feature` Link: Creation date: 2023-10-02 Labels: `A-ABI`, `A-floating-point`, `A-target-feature`, `I-unsound`, `P-high`, `T-compiler`, `T-opsem` Author: `RalfJung` Working groups: Assignees: Notes: by reading [comment](https://github.com/rust-lang/rust/issues/116344#issuecomment-2994393425), I wonder if now only affects phased out i586/i686 targets or legacy 32bit ARM "soft-float" targets ([comment](https://github.com/rust-lang/rust/issues/116344#issuecomment-2575324988)) **TODO** ### #116573: Inlining causes miscompilation of code that mixes target features Link: Creation date: 2023-10-09 Labels: `A-LLVM`, `A-codegen`, `A-target-feature`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler` Author: `RalfJung` Working groups: Assignees: Notes: Upstream LLVM issue: https://github.com/llvm/llvm-project/issues/70563 **TODO** ### #117101: Errors compiling `libc` using rust 1.73.0 on `riscv64/ubuntu:focal` docker image - works with 1.72.1 Link: Creation date: 2023-10-23 Labels: `A-linkage`, `C-bug`, `O-riscv`, `P-high`, `T-compiler`, `regression-from-stable-to-stable`, `regression-untriaged` Author: `emlowe` Working groups: Assignees: **TODO** ### #118099: Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message Link: Creation date: 2023-11-20 Labels: `A-LLVM`, `C-bug`, `O-PowerPC`, `O-netbsd`, `P-high`, `T-compiler` Author: `he32` Working groups: Assignees: Notes: possibly upstream LLVM issue https://github.com/rust-lang/rust/issues/118099#issuecomment-1830852216 **TODO** ### #118223: x86-64 assembler silently truncates 64-bit address Link: Creation date: 2023-11-24 Labels: `A-LLVM`, `A-inline-assembly`, `C-bug`, `I-miscompile`, `I-unsound`, `O-x86_64`, `P-high`, `T-compiler` Author: `MauriceKayser` Working groups: Assignees: Notes: upstream LLVM issue https://github.com/llvm/llvm-project/issues/73481 **TODO** ### #121124: rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr Link: Creation date: 2024-02-15 Labels: `A-LLVM`, `A-LTO`, `C-bug`, `E-needs-investigation`, `E-needs-mcve`, `I-ICE`, `I-unsound`, `O-AArch64`, `O-PowerPC`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `bowlofeggs` Working groups: Assignees: **TODO** ### #122294: f64::round doesn't work properly on arm-unknown-linux-gnueabi Link: Creation date: 2024-03-10 Labels: `A-LLVM`, `C-bug`, `E-needs-investigation`, `I-miscompile`, `I-unsound`, `O-Arm`, `P-high`, `T-compiler` Author: `vklachkov` Working groups: Assignees: **TODO** ### #125033: `-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72 Link: Creation date: 2024-05-12 Labels: `A-LLVM`, `A-target-feature`, `A-targets`, `C-bug`, `I-miscompile`, `I-unsound`, `O-AArch64`, `P-high`, `T-compiler`, `llvm-fixed-upstream` Author: `briansmith` Working groups: Assignees: **TODO** ### #126747: Undefined behavior from stack overflow on wasm32 targets Link: Creation date: 2024-06-20 Labels: `C-bug`, `E-needs-design`, `I-unsound`, `O-wasm`, `P-high`, `T-compiler` Author: `adambratschikaye` Working groups: Assignees: **TODO** ### #127318: Wasm32 miscompilation when using u128 with multivalue and optimizations Link: Creation date: 2024-07-04 Labels: `A-LLVM`, `C-external-bug`, `I-miscompile`, `I-unsound`, `O-wasm`, `P-high`, `S-has-mcve`, `T-compiler` Author: `arriven` Working groups: Assignees: **TODO** ### #127979: Incorrect behavior on Windows with dylibs and ThinLTO Link: Creation date: 2024-07-19 Labels: `A-linkage`, `C-bug`, `C-optimization`, `I-unsound`, `O-windows`, `P-high`, `S-has-mcve`, `T-compiler`, `regression-from-stable-to-stable` Author: `janhohenheim` Working groups: Assignees: **TODO** ### #130834: Invalid metadata for arm64e due to Xcode 15+ on ARM64e macOS Link: Creation date: 2024-09-25 Labels: `C-bug`, `O-Arm`, `O-macos`, `P-high`, `T-bootstrap`, `T-compiler`, `regression-untriaged` Author: `arttet` Working groups: Assignees: **TODO** ### #139370: Performance regression in nightly with target-cpu=native on znver4 Link: Creation date: 2025-04-04 Labels: `A-LLVM`, `C-bug`, `O-x86_64`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `nsarlin-zama` Working groups: Assignees: **TODO** ### #139730: A case of compound x86_64 performance regression caused by LLVM 20 and #124810 Link: Creation date: 2025-04-13 Labels: `A-LLVM`, `C-optimization`, `P-high`, `T-compiler`, `T-libs`, `regression-untriaged` Author: `MoSal` Working groups: Assignees: **TODO** ### #142519: Function no longer auto-vectorizes in 1.87.0 Link: Creation date: 2025-06-14 Labels: `A-LLVM`, `C-optimization`, `I-slow`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `fintelia` Working groups: Assignees: **TODO** ### #143836: regression: ICE compiler/rustc_ty_utils/src/abi.rs:485:62, unwrapping None Link: Creation date: 2025-07-12 Labels: `C-bug`, `I-ICE`, `P-high`, `T-compiler`, `regression-from-stable-to-beta` Author: `Mark-Simulacrum` Working groups: Assignees: **TODO** ### #143992: where bounds regression in beta+nightly Link: Creation date: 2025-07-15 Labels: `A-trait-system`, `C-bug`, `I-types-nominated`, `P-high`, `S-has-bisection`, `S-has-mcve`, `T-compiler`, `T-types`, `regression-from-stable-to-beta` Author: `mejrs` Working groups: Assignees: **TODO** ## P-high T-compiler issues with owner (WG or assignee) ### #47949: Panics in destructors can cause the return value to be leaked Link: Creation date: 2018-02-01 Labels: `A-destructors`, `C-enhancement`, `I-unsound`, `P-high`, `T-compiler`, `T-lang` Author: `arielb1` Working groups: Assignees: `matthewjasper` Notes: PR #125923 was in the making but seems stalled for now ([comment](https://github.com/rust-lang/rust/pull/125923#issuecomment-2987566092)) **TODO** ### #53014: LNK1189 "library limit of 65535 obj exceeded" building rustc Link: Creation date: 2018-08-03 Labels: `A-codegen`, `A-incr-comp`, `A-linkage`, `C-bug`, `E-help-wanted`, `E-needs-design`, `O-windows-msvc`, `P-high`, `P-medium`, `T-compiler`, `WG-incr-comp` Author: `scottmcm` Working groups: `WG-incr-comp` Assignees: `wesleywiser` Notes: Both `P-high` and `P-medium`, already visited in a previous [P-high triage meeting](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202024-11-15.20P-high.20review/near/482641767), see [comment](https://github.com/rust-lang/rust/issues/53014#issuecomment-2479299193). Since then a bit more discussion. **TODO** ### #53934: disambiguate between multiple suggestions and a single multi-span suggestion; or, JSON error format is not round-trippable Link: Creation date: 2018-09-03 Labels: `A-diagnostics`, `C-cleanup`, `D-diagnostic-infra`, `E-mentor`, `E-needs-design`, `P-high`, `T-compiler`, `WG-diagnostics` Author: `zackmdavis` Working groups: `WG-diagnostics` Assignees: Notes: PR #142980 landed a few weeks ago is linked to this issue but unsure how *exactly* **TODO** ### #61275: Varargs are completely unchecked if passed as generics Link: Creation date: 2019-05-28 Labels: `A-FFI`, `I-miscompile`, `I-unsound`, `P-high`, `S-has-mcve`, `T-compiler` Author: `joshuabogue` Working groups: Assignees: `workingjubilee` Notes: I *think* the miscompilation part was closed in #141341. Seems a definitive solution needs more design work **TODO** ### #67497: Switching to opt-level=z on i686-windows-msvc triggers STATUS_ACCESS_VIOLATION Link: Creation date: 2019-12-21 Labels: `A-LLVM`, `C-bug`, `E-needs-investigation`, `E-needs-mcve`, `I-unsound`, `O-windows`, `O-x86_32`, `P-high`, `T-compiler` Author: `dignifiedquire` Working groups: Assignees: `wesleywiser` Notes: visited in a previous P-high review (see [comment](https://github.com/rust-lang/rust/issues/67497#issuecomment-2494000870)). Asked the reporter(s) is the issue still persists, no feedback. Maybe close? **TODO** ### #70022: Statics don't support alignments larger than the page size Link: Creation date: 2020-03-15 Labels: `A-align`, `A-target-specs`, `C-bug`, `E-needs-investigation`, `I-unsound`, `O-linux`, `O-windows-gnu`, `O-windows-msvc`, `P-high`, `T-compiler` Author: `Amanieu` Working groups: Assignees: `pnkfelix` Notes: visited in a previous P-high review ([comment](https://github.com/rust-lang/rust/issues/70022)). By the way, we could probably unassign Felix from [all open issues](https://github.com/rust-lang/rust/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+assignee%3Apnkfelix). **TODO** ### #70143: Locals aligned to greater than page size can cause unsound behavior Link: Creation date: 2020-03-19 Labels: `A-LLVM`, `C-bug`, `C-external-bug`, `I-unsound`, `O-windows`, `P-high`, `T-compiler` Author: `retep998` Working groups: Assignees: `cuviper` Notes: visited during a p-high review in 2022 ([comment](https://github.com/rust-lang/rust/issues/70143#issuecomment-1344458192)) and again in 2024 ([comment](https://github.com/rust-lang/rust/issues/70143#issuecomment-2494035002)). Nothing new since then. Maybe downgrade? **TODO** ### #76360: Error reporting from attribute macros regressed in 1.46.0 Link: Creation date: 2020-09-05 Labels: `A-diagnostics`, `A-proc-macros`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `ahl` Working groups: `WG-diagnostics` Assignees: `estebank` **TODO** ### #79609: Passing `-C panic=abort` still attempts to link in `libunwind` when targeting `i686-pc-windows-gnu` on `v1.44+` Link: Creation date: 2020-12-01 Labels: `A-cross`, `A-linkage`, `A-runtime`, `C-bug`, `O-windows`, `O-x86_32`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `staticfloat` Working groups: Assignees: `wesleywiser` **TODO** ### #83060: Regressions with large (2-4GB) stack arrays on large stacks Link: Creation date: 2021-03-12 Labels: `A-LLVM`, `A-array`, `C-bug`, `E-help-wanted`, `E-medium`, `E-mentor`, `I-unsound`, `P-high`, `T-compiler`, `WG-diagnostics`, `WG-llvm` Author: `joshtriplett` Working groups: `WG-diagnostics`, `WG-llvm` Assignees: `iSwapna`, `wesleywiser` **TODO** ### #84873: Compile time+memory regression between 1.49.0 and 1.50.0 Link: Creation date: 2021-05-03 Labels: `C-bug`, `I-compilemem`, `I-compiletime`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `olix0r` Working groups: Assignees: `pnkfelix` **TODO** ### #86172: Compile error: static lifetime not satisfied but it is Link: Creation date: 2021-06-09 Labels: `A-lifetimes`, `C-bug`, `P-high`, `T-compiler`, `WG-async`, `regression-from-stable-to-stable` Author: `Skepfyr` Working groups: `WG-async` Assignees: **TODO** ### #89626: Undefined reference to `getauxval` in function `init_have_lse_atomics` when compiling to nightly `aarch64-unknown-linux-musl` Link: Creation date: 2021-10-07 Labels: `A-linkage`, `A-linkers`, `C-bug`, `O-Arm`, `O-musl`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `XAMPPRocky` Working groups: Assignees: `pnkfelix` **TODO** ### #90256: Rustc passes syntactically invalid input to attribute macros Link: Creation date: 2021-10-25 Labels: `A-proc-macros`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `dtolnay` Working groups: `WG-diagnostics` Assignees: **TODO** ### #95926: rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default Link: Creation date: 2022-04-11 Labels: `C-bug`, `E-help-wanted`, `E-mentor`, `O-musl`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `joshtriplett` Working groups: `WG-diagnostics` Assignees: **TODO** ### #98746: libcompiler-builtins contains DWARF5 debuginfo in 1.62.0 Link: Creation date: 2022-07-01 Labels: `A-debuginfo`, `C-bug`, `E-needs-mcve`, `E-needs-test`, `P-high`, `T-compiler` Author: `glandium` Working groups: Assignees: `pnkfelix` **TODO** ### #99256: Source of lifetime coercion is not reported starting in 1.63 Link: Creation date: 2022-07-14 Labels: `A-diagnostics`, `A-lifetimes`, `C-bug`, `P-high`, `T-compiler`, `WG-diagnostics`, `regression-from-stable-to-stable` Author: `mqudsi` Working groups: `WG-diagnostics` Assignees: **TODO** ### #100914: LLVM miscompiles large stack allocations Link: Creation date: 2022-08-23 Labels: `A-LLVM`, `C-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-llvm` Author: `Cl00e9ment` Working groups: `WG-llvm` Assignees: `wesleywiser` **TODO** ### #101060: Codegen weirdness for `sum` of `count_ones` over an array Link: Creation date: 2022-08-26 Labels: `A-LLVM`, `A-autovectorization`, `A-codegen`, `C-bug`, `I-slow`, `O-x86_64`, `P-high`, `T-compiler`, `WG-llvm`, `regression-from-stable-to-stable` Author: `alion02` Working groups: `WG-llvm` Assignees: **TODO** ### #101346: Incorrect handling of lateout pairs in inline asm Link: Creation date: 2022-09-02 Labels: `A-LLVM`, `A-inline-assembly`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-none` Author: `newpavlov` Working groups: `WG-none` Assignees: `nikic` **TODO** ### #102174: extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO Link: Creation date: 2022-09-23 Labels: `A-ABI`, `A-FFI`, `A-LLVM`, `A-LTO`, `C-bug`, `I-unsound`, `O-x86_32`, `P-high`, `T-compiler`, `WG-llvm`, `regression-untriaged` Author: `glandium` Working groups: `WG-llvm` Assignees: **TODO** ### #102754: ld64.lld: error: too many personalities (4) for compact unwind to encode Link: Creation date: 2022-10-06 Labels: `A-linkage`, `C-bug`, `O-ios`, `O-macos`, `P-high`, `T-compiler`, `regression-from-stable-to-stable`, `relnotes` Author: `glandium` Working groups: Assignees: `pnkfelix` **TODO** ### #107975: Miscompilation: Equal pointers comparing as unequal Link: Creation date: 2023-02-13 Labels: `A-LLVM`, `C-external-bug`, `I-miscompile`, `I-unsound`, `P-high`, `T-compiler`, `WG-llvm` Author: `JakobDegen` Working groups: `WG-llvm` Assignees: **TODO** ### #108216: miscompilation with incremental + unpacked debug + macos Link: Creation date: 2023-02-18 Labels: `A-incr-comp`, `C-bug`, `I-unsound`, `O-macos`, `P-high`, `T-compiler`, `regression-from-stable-to-stable` Author: `ehuss` Working groups: Assignees: `lqd` **TODO** ### #109114: `-Zdylib-lto` with ThinLTO is broken on windows-msvc Link: Creation date: 2023-03-14 Labels: `A-LLVM`, `A-LTO`, `I-miscompile`, `I-unsound`, `O-windows-msvc`, `P-high`, `T-compiler`, `WG-llvm`, `requires-nightly` Author: `Noratrieb` Working groups: `WG-llvm` Assignees: **TODO** ### #110174: Floating point comparisons are miscompiled for signalling NaN inputs on AArch64 Link: Creation date: 2023-04-11 Labels: `A-LLVM`, `A-floating-point`, `C-external-bug`, `I-miscompile`, `I-unsound`, `O-AArch64`, `P-high`, `T-compiler`, `WG-llvm`, `regression-from-stable-to-stable` Author: `thomcc` Working groups: `WG-llvm` Assignees: **TODO** ### #111229: mutable_transmutes lint should catch transmutes from a type without interior mutability to one with Link: Creation date: 2023-05-05 Labels: `A-LLVM`, `A-lints`, `C-bug`, `P-high`, `T-compiler` Author: `glandium` Working groups: Assignees: `ChayimFriedman2` **TODO** ### #131960: Regression: geoarrow crate does not compile in release mode on 1.82 Link: Creation date: 2024-10-20 Labels: `A-mir-opt-inlining`, `C-bug`, `P-high`, `T-compiler`, `T-types`, `WG-mir-opt`, `regression-from-stable-to-stable` Author: `theemathas` Working groups: `WG-mir-opt` Assignees: **TODO** ### #132673: Hang after encountering overflow errors for huge types Link: Creation date: 2024-11-06 Labels: `A-diagnostics`, `C-bug`, `I-hang`, `P-high`, `S-has-mcve`, `T-compiler`, `regression-from-stable-to-stable` Author: `wxie7` Working groups: Assignees: `compiler-errors` **TODO** ### #141006: `lemmy_db_views_modlog_combined` has a weird performance regression Link: Creation date: 2025-05-14 Labels: `C-bug`, `E-needs-mcve`, `I-compiletime`, `P-high`, `T-compiler`, `regression-untriaged` Author: `lcnr` Working groups: Assignees: `steffahn` **TODO** --- ### Minutes Triage Meeting 2026 Q2 T Compiler P High Issue Review (Round 2) (`content/minutes/triage-meeting/2026 Q2 T-compiler P-high Issue Review (round 2).md`) --- title: T-compiler P-high issues tags: p-high-issues note_id: H7ikp7ypTXeroPEVJ6HSWQ --- # 2026 Q2 T-compiler P-high Issue Review (round 2) Issues snapshot collected on: 2026-07-30 ## Table of contents: - [P-high T-compiler issues unassigned](#P-high-T-compiler-issues-unassigned) (50) - [P-high T-compiler issues assigned](#P-high-T-compiler-issues-assigned) (43) - [P-high without a team label](#P-high-without-a-team-label) (0) ## P-high T-compiler issues unassigned ### "Compile time+memory regression between 1.49.0 and 1.50.0" [rust#84873](https://github.com/rust-lang/rust/issues/84873) Creation date: 63 months ago Update at: 12 months ago Labels: [I-compiletime, P-high, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug] Author: `olix0r` Assignees: `none` Working groups: Notes: Probably downgrade. Last [triage in 2022](https://github.com/rust-lang/rust/issues/84873#issuecomment-1320995012), seems that part of the perf. regression was recovered. It's all very old and authors didn't get back to us. Worth leaving a comment and ask to retest? Possibly close the issue given its age. Triage: ### "Compile error: static lifetime not satisfied but it is" [rust#86172](https://github.com/rust-lang/rust/issues/86172) Creation date: 62 months ago Update at: 18 months ago Labels: [A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-async] Author: `Skepfyr` Assignees: `none` Working groups: Notes: Probably downgrade: last triage [3 years ago](https://github.com/rust-lang/rust/issues/86172#issuecomment-1320194292), this [comment](https://github.com/rust-lang/rust/issues/86172#issuecomment-1553335675) indicates could be a duplicate of #71723 Triage: ### "Rustc passes syntactically invalid input to attribute macros" [rust#90256](https://github.com/rust-lang/rust/issues/90256) Creation date: 57 months ago Update at: 40 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, WG-diagnostics, A-proc-macros] Author: `dtolnay` Assignees: `none` Working groups: Notes: probably downgrade. Was triaged multiple times but no action followed up Triage: ### "rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default" [rust#95926](https://github.com/rust-lang/rust/issues/95926) Creation date: TODO Update at: 31 months ago Labels: [E-mentor, P-high, T-compiler, regression-from-stable-to-stable, E-help-wanted, O-musl, C-bug, WG-diagnostics] Author: `joshtriplett` Assignees: `` Working groups: Notes: Probably downgrade. Very old issue, last [triage 3y ago](https://github.com/rust-lang/rust/issues/95926#issuecomment-1508655129) and `musl` targets are all Tier 2. Needs an owner. Triage: ### "libcompiler-builtins contains DWARF5 debuginfo in 1.62.0" [rust#98746](https://github.com/rust-lang/rust/issues/98746) Creation date: TODO Update at: 10 months ago Labels: [A-debuginfo, E-needs-test, P-high, T-compiler, C-bug, E-needs-mcve] Author: `glandium` Assignees: `` Working groups: Notes: Maybe close as [this comment](https://github.com/rust-lang/rust/issues/98746#issuecomment-3137298203) suggest? Though as the next comment suggest, what's the status of DWARF6 in LLVM? Triage: ### "Source of lifetime coercion is not reported starting in 1.63" [rust#99256](https://github.com/rust-lang/rust/issues/99256) Creation date: TODO Update at: 41 months ago Labels: [A-diagnostics, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-diagnostics] Author: `mqudsi` Assignees: `` Working groups: Notes: maybe downgrade? That diag error is still there, I don't think we're going to fix that anytime soon Triage: ### "Codegen weirdness for `sum` of `count_ones` over an array" [rust#101060](https://github.com/rust-lang/rust/issues/101060) Creation date: TODO Update at: 30 months ago Labels: [A-LLVM, I-slow, A-codegen, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-llvm, A-autovectorization] Author: `alion02` Assignees: `` Working groups: Notes: maybe close? The last [comment](https://github.com/rust-lang/rust/issues/101060#issuecomment-1870396121) indicates that the codegen is what was expected before the regression. Tested the godbolt link and it's still the same Triage: ### "extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO" [rust#102174](https://github.com/rust-lang/rust/issues/102174) Creation date: 46 months ago Update at: 12 months ago Labels: [A-LLVM, A-FFI, P-high, T-compiler, I-unsound, C-bug, WG-llvm, regression-untriaged, A-LTO, A-ABI, O-x86_32] Author: `glandium` Assignees: `none` Working groups: Notes: Previously [triaged](https://github.com/rust-lang/rust/issues/102174#issuecomment-1285502667). IIUC Nikic had a plan to solve this and #143818 ([comment](https://github.com/rust-lang/rust/issues/143818#issuecomment-3073987289)) but unclear the progress. I would probably ping him again before deciding to downgrade the issue. Triage: ### "Broken compilation with `&(dyn Trait + '_)`" [rust#103762](https://github.com/rust-lang/rust/issues/103762) Creation date: 45 months ago Update at: 20 months ago Labels: [A-resolve, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `Cerber-Ursi` Assignees: `none` Working groups: Notes: [Bisection](https://github.com/rust-lang/rust/issues/103762#issuecomment-1305053189) at the time pointed at https://github.com/rust-lang/rust/pull/97720, specifically, [this change here](https://github.com/rust-lang/rust/pull/97720/files?diff=unified&w=0#diff-809615be77d084b910459cf54c39f25745f5b9f8ad9e50c2a33e7fc2573686f1L761-R764). Would probably downgrade or even close given it's a deprecated syntax. Triage: ### "Miscompilation: Equal pointers comparing as unequal" [rust#107975](https://github.com/rust-lang/rust/issues/107975) Creation date: 42 months ago Update at: 14 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, WG-llvm, I-miscompile, C-external-bug] Author: `JakobDegen` Assignees: `none` Working groups: Notes: Some triaging [at the time](https://github.com/rust-lang/rust/issues/107975#issuecomment-1430188404) indicate that it's not a regression and [comment](https://github.com/rust-lang/rust/issues/107975#issuecomment-1430751296) points to https://github.com/llvm/llvm-project/issues/45725. Nikita comments [here](https://github.com/rust-lang/rust/issues/107975#issuecomment-1439817961). The issue is still present and I *think* still deserves a P-high but after skimming the long discussion no actionable was found. Triage: ### "`-Zdylib-lto` with ThinLTO is broken on windows-msvc" [rust#109114](https://github.com/rust-lang/rust/issues/109114) Creation date: 41 months ago Update at: 22 months ago Labels: [A-LLVM, P-high, T-compiler, O-windows-msvc, I-unsound, WG-llvm, requires-nightly, A-LTO, I-miscompile] Author: `Noratrieb` Assignees: `none` Working groups: Notes: hopefully this was "fixed" by #122790 but probably needs a test on that platform. Triage: ### "ICE: unexpected initial operand type." [rust#114858](https://github.com/rust-lang/rust/issues/114858) Creation date: 36 months ago Update at: about 24 days ago Labels: [I-ICE, P-high, T-compiler, regression-from-stable-to-stable, C-bug, E-needs-investigation] Author: `fakeshadow` Assignees: `none` Working groups: Notes: Still labeled `E-needs-investigation`, still reproduces today. Was [downgraded](https://github.com/rust-lang/rust/issues/114858#issuecomment-1739378909) to P-high. Triage: ### "The ABI of float types can be changed by `-Ctarget-feature`" [rust#116344](https://github.com/rust-lang/rust/issues/116344) Creation date: 34 months ago Update at: 12 months ago Labels: [P-high, T-compiler, I-unsound, C-tracking-issue, A-floating-point, A-ABI, A-target-feature, T-opsem] Author: `RalfJung` Assignees: `none` Working groups: Notes: still reproduces, looks complicated, current status in the opening [comment](https://github.com/rust-lang/rust/issues/116344#issue-1921985365). Still feels P-high. Triage: ### "Inlining causes miscompilation of code that mixes target features" [rust#116573](https://github.com/rust-lang/rust/issues/116573) Creation date: 34 months ago Update at: about 23 days ago Labels: [A-LLVM, A-codegen, P-high, T-compiler, I-unsound, C-bug, WG-llvm, A-target-feature, llvm-fixed-upstream, I-miscompile] Author: `RalfJung` Assignees: `none` Working groups: Notes: Recent [comment](https://github.com/rust-lang/rust/issues/116573#issuecomment-4799085817) indicates that it was fixed by LLVM upstream. We could leave it as P-high and close it when that LLVM patch lands by us over an update. Triage: ### "Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message" [rust#118099](https://github.com/rust-lang/rust/issues/118099) Creation date: 32 months ago Update at: 32 months ago Labels: [A-LLVM, P-high, T-compiler, O-netbsd, O-PowerPC, C-bug] Author: `he32` Assignees: `none` Working groups: Notes: As per [comment](https://github.com/rust-lang/rust/issues/118099#issuecomment-1830844221): issue was with the LLVM shipped with rust 1.73. LLVM with Rust 1.74 apparently fixed. So in the end they were stuck with a Rust 1.73 that had another problem. Unsure how it evolved since then. Maybe downgrade and/or ask for an update? Triage: ### "x86-64 assembler silently truncates 64-bit address" [rust#118223](https://github.com/rust-lang/rust/issues/118223) Creation date: 32 months ago Update at: 3 months ago Labels: [A-LLVM, O-x86_64, A-inline-assembly, P-high, T-compiler, I-unsound, C-bug, llvm-fixed-upstream, I-miscompile] Author: `MauriceKayser` Assignees: `none` Working groups: Notes: Issue was fixed in LLVM 22/rust 1.95 ([comment](https://github.com/rust-lang/rust/issues/118223#issuecomment-4262064843)) but there are still problematic instructions. Let's keep it open - maybe see if this is tracked on the LLVM side? Feels still P-high. Triage: ### "rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr" [rust#121124](https://github.com/rust-lang/rust/issues/121124) Creation date: 29 months ago Update at: 9 months ago Labels: [A-LLVM, I-ICE, P-high, T-compiler, regression-from-stable-to-stable, I-unsound, O-PowerPC, C-bug, E-needs-mcve, A-LTO, O-AArch64, E-needs-investigation] Author: `bowlofeggs` Assignees: `none` Working groups: Notes: I remember this issue ^^'. Need investigation. Unsure if Gentoo in the meantime moved to newer rust buildchains. Triage: ### "`-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72" [rust#125033](https://github.com/rust-lang/rust/issues/125033) Creation date: 26 months ago Update at: 16 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, O-AArch64, A-target-feature, llvm-fixed-upstream, A-targets, I-miscompile] Author: `briansmith` Assignees: `none` Working groups: Notes: The issue itself seems fixed by LLVM upstream ([comment](https://github.com/rust-lang/rust/issues/125033#issuecomment-2389581790)) but reporter mentions a more general LLVM issue ([comment](https://github.com/rust-lang/rust/issues/125033#issuecomment-2631507945)) with `cfg(target_feature)`, unsure how it if warrants a separate discussion. It's under "ARM Maintainer", @*davidtwco* do you happen to know more? Triage: ### "Undefined behavior from stack overflow on wasm32 targets" [rust#126747](https://github.com/rust-lang/rust/issues/126747) Creation date: 25 months ago Update at: 20 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, E-needs-design] Author: `adambratschikaye` Assignees: `none` Working groups: Notes: This needs design from someone familiar with the target. Unsure if this means the issue can be downgraded. We probably don't need to triage every time here until that has happened. Triage: ### "Wasm32 miscompilation when using u128 with multivalue and optimizations" [rust#127318](https://github.com/rust-lang/rust/issues/127318) Creation date: 25 months ago Update at: 20 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, O-wasm, S-has-mcve, I-miscompile, C-external-bug] Author: `arriven` Assignees: `none` Working groups: Notes: Triage: ### "Hang after encountering overflow errors for huge types " [rust#132673](https://github.com/rust-lang/rust/issues/132673) Creation date: 21 months ago Update at: about 41 days ago Labels: [A-diagnostics, P-high, T-compiler, regression-from-stable-to-stable, C-bug, I-hang, S-has-mcve] Author: `ym-xie` Assignees: `none` Working groups: Notes: Triage: ### "non-`#[macro_export]`'ed `macro_rules!` macros are impossible to disambiguate from built-in attributes in `use` declarations" [rust#133708](https://github.com/rust-lang/rust/issues/133708) Creation date: 20 months ago Update at: about 5 days ago Labels: [A-attributes, A-resolve, A-macros, P-high, T-lang, T-compiler, C-bug] Author: `kanashimia` Assignees: `none` Working groups: Notes: Triage: ### "aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature (tracking issue for `aarch64_softfloat_neon`)" [rust#134375](https://github.com/rust-lang/rust/issues/134375) Creation date: 19 months ago Update at: 11 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, C-tracking-issue, O-AArch64, A-ABI, A-target-feature] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "Performance regression in nightly with target-cpu=native on znver4" [rust#139370](https://github.com/rust-lang/rust/issues/139370) Creation date: 16 months ago Update at: 6 months ago Labels: [A-LLVM, I-slow, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `nsarlin-zama` Assignees: `none` Working groups: Notes: Triage: ### "const-eval can construct uninhabited values or other unconstructable values out-of-thin-air via recursive static initialization" [rust#143047](https://github.com/rust-lang/rust/issues/143047) Creation date: 13 months ago Update at: 2 months ago Labels: [P-high, T-lang, T-compiler, I-unsound, C-bug, A-rust-for-linux, I-lang-radar] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "Destructor of packed structs can move dangling references." [rust#143411](https://github.com/rust-lang/rust/issues/143411) Creation date: 13 months ago Update at: 11 months ago Labels: [A-destructors, P-high, T-compiler, I-unsound, C-bug, T-opsem, A-repr-packed] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "Potentially-observable store gets elided: asm block does not act as a compiler fence" [rust#144351](https://github.com/rust-lang/rust/issues/144351) Creation date: 12 months ago Update at: 2 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "1.90 regression: Cycle detected when type checking" [rust#146813](https://github.com/rust-lang/rust/issues/146813) Creation date: 10 months ago Update at: 10 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug, S-has-mcve, T-types, fixed-by-next-solver, I-cycle, S-has-bisection] Author: `Totodore` Assignees: `none` Working groups: Notes: Triage: ### "SignatureMismatch ICE" [rust#146965](https://github.com/rust-lang/rust/issues/146965) Creation date: 10 months ago Update at: 4 months ago Labels: [I-ICE, A-trait-system, A-associated-items, P-high, T-compiler, regression-from-stable-to-stable, C-bug, A-mir-opt, A-mir-opt-inlining, S-has-mcve, S-bug-has-test, T-types, fixed-by-next-solver] Author: `benruijl` Assignees: `none` Working groups: Notes: Triage: ### "catch_unwind doesn't catch non-C++ exceptions on wasm" [rust#148273](https://github.com/rust-lang/rust/issues/148273) Creation date: 9 months ago Update at: 6 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, T-libs, WG-ffi-unwind] Author: `bjorn3` Assignees: `none` Working groups: Notes: Triage: ### "`derive(PartialEq)` on enums is unsound with user-defined attribute macros." [rust#148423](https://github.com/rust-lang/rust/issues/148423) Creation date: 8 months ago Update at: 3 months ago Labels: [A-macros, P-high, T-lang, T-compiler, I-unsound, C-bug, T-libs, A-proc-macros, I-lang-radar] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "rustc does not always update the mtime of all its outputs" [rust#148948](https://github.com/rust-lang/rust/issues/148948) Creation date: 8 months ago Update at: 8 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "TrivialClone is not derived for generic types (Performance regression)" [rust#149752](https://github.com/rust-lang/rust/issues/149752) Creation date: 7 months ago Update at: 4 months ago Labels: [A-macros, P-high, T-compiler, regression-from-stable-to-stable, A-specialization, C-bug, T-libs, T-types] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "ICE in release builds from 1.90.0 onwards" [rust#150263](https://github.com/rust-lang/rust/issues/150263) Creation date: 7 months ago Update at: 4 months ago Labels: [I-ICE, A-trait-system, A-associated-items, P-high, T-compiler, regression-from-stable-to-stable, C-bug, A-mir-opt, A-mir-opt-inlining, S-has-mcve, S-bug-has-test, T-types, fixed-by-next-solver] Author: `zxqfd555` Assignees: `none` Working groups: Notes: Triage: ### "compiler-builtins aarch64 outline atomics symbols do not work with BTI" [rust#151486](https://github.com/rust-lang/rust/issues/151486) Creation date: 6 months ago Update at: 5 months ago Labels: [P-high, T-compiler, C-bug, T-libs, O-AArch64, A-atomic, A-target-feature] Author: `zmodem` Assignees: `none` Working groups: Notes: Triage: ### "LLVM loop miscompilation" [rust#153222](https://github.com/rust-lang/rust/issues/153222) Creation date: 5 months ago Update at: 5 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, I-miscompile] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "Significant compilation time regression starting in v1.95.0-nightly (bevy)" [rust#153910](https://github.com/rust-lang/rust/issues/153910) Creation date: 4 months ago Update at: 3 months ago Labels: [A-trait-system, I-compiletime, P-high, T-compiler, E-medium, C-bug, E-needs-mcve, T-types] Author: `gpoblon` Assignees: `none` Working groups: Notes: Triage: ### "Unsoundness and ICE due to string literals that are too long for a 32-bit platform" [rust#156846](https://github.com/rust-lang/rust/issues/156846) Creation date: 2 months ago Update at: about 27 days ago Labels: [I-ICE, P-high, T-compiler, I-unsound, C-bug, A-layout, A-str, needs-triage] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "Regression: unnecessary stack frame generated for arm-none-eabi targets" [rust#157163](https://github.com/rust-lang/rust/issues/157163) Creation date: 2 months ago Update at: about 59 days ago Labels: [O-Arm, P-high, T-compiler, C-bug, I-heavy, regression-untriaged] Author: `nhpupu` Assignees: `none` Working groups: Notes: Triage: ### "Regression: Wasm32 SIMD128 narrow intrinsics stopped working correctly in Rust 1.95+" [rust#157456](https://github.com/rust-lang/rust/issues/157456) Creation date: about 55 days ago Update at: about 41 days ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, O-wasm, A-SIMD, C-bug, llvm-fixed-upstream, I-miscompile] Author: `Cykooz` Assignees: `none` Working groups: Notes: Triage: ### "Regression 1.96.1 → 1.97.0: "missing optimized MIR" for pub fn glob-reexported alongside a restricted glob duplicate" [rust#159038](https://github.com/rust-lang/rust/issues/159038) Creation date: about 20 days ago Update at: about 16 days ago Labels: [A-resolve, A-visibility, P-high, T-compiler, regression-from-stable-to-stable, C-bug, S-has-bisection] Author: `calvinrp` Assignees: `none` Working groups: Notes: Triage: ### "1.98 beta regression: "queries overflow the depth limit!"" [rust#159427](https://github.com/rust-lang/rust/issues/159427) Creation date: about 13 days ago Update at: about 9 days ago Labels: [P-high, T-compiler, regression-from-stable-to-beta, C-bug, A-async-await, S-has-mcve, S-has-bisection] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "1.98 beta regression due to name collision with `unroll`" [rust#159429](https://github.com/rust-lang/rust/issues/159429) Creation date: about 13 days ago Update at: about 0 days ago Labels: [A-attributes, A-resolve, A-macros, P-high, T-compiler, regression-from-stable-to-beta, C-bug, I-lang-nominated] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "EarlyOtherwiseBranch introduces access to a dead local variable" [rust#159618](https://github.com/rust-lang/rust/issues/159618) Creation date: about 9 days ago Update at: about 2 days ago Labels: [P-high, T-compiler, C-bug, A-mir-opt, I-miscompile] Author: `tmiasko` Assignees: `none` Working groups: Notes: Triage: ### "GVN pass introduces UB by reborrowing from disabled reference" [rust#160004](https://github.com/rust-lang/rust/issues/160004) Creation date: about 3 days ago Update at: about 3 days ago Labels: [P-high, T-compiler, I-unsound, C-bug, A-mir-opt, T-opsem, I-miscompile, A-mir-opt-GVN] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ## P-high T-compiler issues assigned ### "Varargs are completely unchecked if passed as generics" [rust#61275](https://github.com/rust-lang/rust/issues/61275) Creation date: 87 months ago Update at: 4 months ago Labels: [A-FFI, P-high, T-compiler, I-unsound, S-has-mcve, I-miscompile] Author: `joshuabogue` Assignees: `[workingjubilee]` Working groups: Notes: Triage: ### "Switching to opt-level=z on i686-windows-msvc triggers STATUS_ACCESS_VIOLATION" [rust#67497](https://github.com/rust-lang/rust/issues/67497) Creation date: 80 months ago Update at: about 38 days ago Labels: [A-LLVM, O-windows, P-high, T-compiler, I-unsound, C-bug, E-needs-mcve, O-x86_32, E-needs-investigation] Author: `dignifiedquire` Assignees: `[wesleywiser]` Working groups: Notes: Triage: ### "Statics don't support alignments larger than the page size" [rust#70022](https://github.com/rust-lang/rust/issues/70022) Creation date: 77 months ago Update at: 12 months ago Labels: [O-linux, P-high, T-compiler, O-windows-gnu, O-windows-msvc, I-unsound, A-target-specs, C-bug, E-needs-investigation, A-align] Author: `Amanieu` Assignees: `none` Working groups: Notes: maybe downgrade at this point? [triaged again in 2024](https://github.com/rust-lang/rust/issues/70022#issuecomment-2494019524) Triage: ### "Locals aligned to greater than page size can cause unsound behavior" [rust#70143](https://github.com/rust-lang/rust/issues/70143) Creation date: 77 months ago Update at: about 40 days ago Labels: [A-LLVM, O-windows, P-high, T-compiler, I-unsound, C-bug, E-needs-investigation, C-external-bug] Author: `retep998` Assignees: `[cuviper]` Working groups: Notes: Triage: ### "Passing `-C panic=abort` still attempts to link in `libunwind` when targeting `i686-pc-windows-gnu` on `v1.44+`" [rust#79609](https://github.com/rust-lang/rust/issues/79609) Creation date: 68 months ago Update at: about 41 days ago Labels: [A-runtime, A-linkage, O-windows, A-cross, P-high, T-compiler, regression-from-stable-to-stable, C-bug, O-x86_32, fixed-by-build-std] Author: `staticfloat` Assignees: `[wesleywiser]` Working groups: Notes: Triage: ### "Compile time+memory regression between 1.49.0 and 1.50.0" [rust#84873](https://github.com/rust-lang/rust/issues/84873) Creation date: 63 months ago Update at: 12 months ago Labels: [I-compiletime, P-high, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug] Author: `olix0r` Assignees: `none` Working groups: Notes: part of the regression war recovered (see [comment](https://github.com/rust-lang/rust/issues/84873#issuecomment-1320995012)) Triage: ### "Compile error: static lifetime not satisfied but it is" [rust#86172](https://github.com/rust-lang/rust/issues/86172) Creation date: 62 months ago Update at: 18 months ago Labels: [A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-async] Author: `Skepfyr` Assignees: `none` Working groups: Notes: Triage: ### "Rustc passes syntactically invalid input to attribute macros" [rust#90256](https://github.com/rust-lang/rust/issues/90256) Creation date: 57 months ago Update at: 40 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, WG-diagnostics, A-proc-macros] Author: `dtolnay` Assignees: `none` Working groups: Notes: Triage: ### "rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default" [rust#95926](https://github.com/rust-lang/rust/issues/95926) Creation date: 52 months ago Update at: 33 months ago Labels: [E-mentor, P-high, T-compiler, regression-from-stable-to-stable, E-help-wanted, O-musl, C-bug, WG-diagnostics] Author: `joshtriplett` Assignees: `none` Working groups: Notes: Triage: ### "libcompiler-builtins contains DWARF5 debuginfo in 1.62.0" [rust#98746](https://github.com/rust-lang/rust/issues/98746) Creation date: 49 months ago Update at: 12 months ago Labels: [A-debuginfo, E-needs-test, P-high, T-compiler, C-bug, E-needs-mcve] Author: `glandium` Assignees: `none` Working groups: Notes: Triage: ### "Source of lifetime coercion is not reported starting in 1.63" [rust#99256](https://github.com/rust-lang/rust/issues/99256) Creation date: 49 months ago Update at: 43 months ago Labels: [A-diagnostics, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-diagnostics] Author: `mqudsi` Assignees: `none` Working groups: Notes: Triage: ### "LLVM miscompiles large stack allocations" [rust#100914](https://github.com/rust-lang/rust/issues/100914) Creation date: 47 months ago Update at: about 41 days ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, WG-llvm, I-miscompile] Author: `Cl00e9ment` Assignees: `[wesleywiser]` Working groups: Notes: Triage: ### "Codegen weirdness for `sum` of `count_ones` over an array" [rust#101060](https://github.com/rust-lang/rust/issues/101060) Creation date: 47 months ago Update at: 31 months ago Labels: [A-LLVM, I-slow, A-codegen, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-llvm, A-autovectorization] Author: `alion02` Assignees: `none` Working groups: Notes: Triage: ### "extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO" [rust#102174](https://github.com/rust-lang/rust/issues/102174) Creation date: 46 months ago Update at: 12 months ago Labels: [A-LLVM, A-FFI, P-high, T-compiler, I-unsound, C-bug, WG-llvm, regression-untriaged, A-LTO, A-ABI, O-x86_32] Author: `glandium` Assignees: `none` Working groups: Notes: Triage: ### "ld64.lld: error: too many personalities (4) for compact unwind to encode" [rust#102754](https://github.com/rust-lang/rust/issues/102754) Creation date: 46 months ago Update at: 12 months ago Labels: [A-linkage, O-macos, O-ios, P-high, T-compiler, relnotes, regression-from-stable-to-stable, C-bug] Author: `glandium` Assignees: `none` Working groups: Notes: Triage: ### "Broken compilation with `&(dyn Trait + '_)`" [rust#103762](https://github.com/rust-lang/rust/issues/103762) Creation date: 45 months ago Update at: 20 months ago Labels: [A-resolve, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `Cerber-Ursi` Assignees: `none` Working groups: Notes: Triage: ### "Miscompilation: Equal pointers comparing as unequal" [rust#107975](https://github.com/rust-lang/rust/issues/107975) Creation date: 42 months ago Update at: 14 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, WG-llvm, I-miscompile, C-external-bug] Author: `JakobDegen` Assignees: `none` Working groups: Notes: Triage: ### "`-Zdylib-lto` with ThinLTO is broken on windows-msvc" [rust#109114](https://github.com/rust-lang/rust/issues/109114) Creation date: 41 months ago Update at: 22 months ago Labels: [A-LLVM, P-high, T-compiler, O-windows-msvc, I-unsound, WG-llvm, requires-nightly, A-LTO, I-miscompile] Author: `Noratrieb` Assignees: `none` Working groups: Notes: Triage: ### "ICE: unexpected initial operand type." [rust#114858](https://github.com/rust-lang/rust/issues/114858) Creation date: 36 months ago Update at: about 24 days ago Labels: [I-ICE, P-high, T-compiler, regression-from-stable-to-stable, C-bug, E-needs-investigation] Author: `fakeshadow` Assignees: `none` Working groups: Notes: Triage: ### "Inlining causes miscompilation of code that mixes target features" [rust#116573](https://github.com/rust-lang/rust/issues/116573) Creation date: 34 months ago Update at: about 23 days ago Labels: [A-LLVM, A-codegen, P-high, T-compiler, I-unsound, C-bug, WG-llvm, A-target-feature, llvm-fixed-upstream, I-miscompile] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message" [rust#118099](https://github.com/rust-lang/rust/issues/118099) Creation date: 32 months ago Update at: 32 months ago Labels: [A-LLVM, P-high, T-compiler, O-netbsd, O-PowerPC, C-bug] Author: `he32` Assignees: `none` Working groups: Notes: Triage: ### "x86-64 assembler silently truncates 64-bit address" [rust#118223](https://github.com/rust-lang/rust/issues/118223) Creation date: 32 months ago Update at: 3 months ago Labels: [A-LLVM, O-x86_64, A-inline-assembly, P-high, T-compiler, I-unsound, C-bug, llvm-fixed-upstream, I-miscompile] Author: `MauriceKayser` Assignees: `none` Working groups: Notes: Triage: ### "rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr" [rust#121124](https://github.com/rust-lang/rust/issues/121124) Creation date: 29 months ago Update at: 9 months ago Labels: [A-LLVM, I-ICE, P-high, T-compiler, regression-from-stable-to-stable, I-unsound, O-PowerPC, C-bug, E-needs-mcve, A-LTO, O-AArch64, E-needs-investigation] Author: `bowlofeggs` Assignees: `none` Working groups: Notes: Triage: ### "`-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72" [rust#125033](https://github.com/rust-lang/rust/issues/125033) Creation date: 26 months ago Update at: 16 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, O-AArch64, A-target-feature, llvm-fixed-upstream, A-targets, I-miscompile] Author: `briansmith` Assignees: `none` Working groups: Notes: Triage: ### "Undefined behavior from stack overflow on wasm32 targets" [rust#126747](https://github.com/rust-lang/rust/issues/126747) Creation date: 25 months ago Update at: 20 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, E-needs-design] Author: `adambratschikaye` Assignees: `none` Working groups: Notes: Triage: ### "Wasm32 miscompilation when using u128 with multivalue and optimizations" [rust#127318](https://github.com/rust-lang/rust/issues/127318) Creation date: 25 months ago Update at: 20 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, O-wasm, S-has-mcve, I-miscompile, C-external-bug] Author: `arriven` Assignees: `none` Working groups: Notes: Triage: ### "Hang after encountering overflow errors for huge types " [rust#132673](https://github.com/rust-lang/rust/issues/132673) Creation date: 21 months ago Update at: about 41 days ago Labels: [A-diagnostics, P-high, T-compiler, regression-from-stable-to-stable, C-bug, I-hang, S-has-mcve] Author: `ym-xie` Assignees: `none` Working groups: Notes: Triage: ### "aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature (tracking issue for `aarch64_softfloat_neon`)" [rust#134375](https://github.com/rust-lang/rust/issues/134375) Creation date: 19 months ago Update at: 11 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, C-tracking-issue, O-AArch64, A-ABI, A-target-feature] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "Performance regression in nightly with target-cpu=native on znver4" [rust#139370](https://github.com/rust-lang/rust/issues/139370) Creation date: 16 months ago Update at: 6 months ago Labels: [A-LLVM, I-slow, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `nsarlin-zama` Assignees: `none` Working groups: Notes: Triage: ### "`lemmy_db_views_modlog_combined` has a weird performance regression" [rust#141006](https://github.com/rust-lang/rust/issues/141006) Creation date: 14 months ago Update at: about 24 days ago Labels: [I-compiletime, P-high, T-compiler, C-bug, E-needs-mcve, regression-untriaged] Author: `lcnr` Assignees: `[steffahn]` Working groups: Notes: Triage: ### "Potentially-observable store gets elided: asm block does not act as a compiler fence" [rust#144351](https://github.com/rust-lang/rust/issues/144351) Creation date: 12 months ago Update at: 2 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "rustc does not always update the mtime of all its outputs" [rust#148948](https://github.com/rust-lang/rust/issues/148948) Creation date: 8 months ago Update at: 8 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `RalfJung` Assignees: `none` Working groups: Notes: Triage: ### "Performance regression (30%) between Rust 1.90 and 1.91" [rust#153154](https://github.com/rust-lang/rust/issues/153154) Creation date: 5 months ago Update at: about 43 days ago Labels: [A-LLVM, I-slow, P-high, T-compiler, C-bug, regression-untriaged, needs-triage] Author: `plafer` Assignees: `[dianqk]` Working groups: Notes: Triage: ### "LLVM loop miscompilation" [rust#153222](https://github.com/rust-lang/rust/issues/153222) Creation date: 5 months ago Update at: 5 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, I-miscompile] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "rustc has stopped emitting unused `repr`/`link`/`panic_handler` attribute lints on macro invocations" [rust#156499](https://github.com/rust-lang/rust/issues/156499) Creation date: 2 months ago Update at: about 58 days ago Labels: [A-attributes, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `mejrs` Assignees: `[JonathanBrouwer]` Working groups: Notes: Triage: ### "Unsoundness and ICE due to string literals that are too long for a 32-bit platform" [rust#156846](https://github.com/rust-lang/rust/issues/156846) Creation date: 2 months ago Update at: about 27 days ago Labels: [I-ICE, P-high, T-compiler, I-unsound, C-bug, A-layout, A-str, needs-triage] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "Regression: unnecessary stack frame generated for arm-none-eabi targets" [rust#157163](https://github.com/rust-lang/rust/issues/157163) Creation date: 2 months ago Update at: about 59 days ago Labels: [O-Arm, P-high, T-compiler, C-bug, I-heavy, regression-untriaged] Author: `nhpupu` Assignees: `none` Working groups: Notes: Triage: ### "Regression: Wasm32 SIMD128 narrow intrinsics stopped working correctly in Rust 1.95+" [rust#157456](https://github.com/rust-lang/rust/issues/157456) Creation date: about 55 days ago Update at: about 41 days ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, O-wasm, A-SIMD, C-bug, llvm-fixed-upstream, I-miscompile] Author: `Cykooz` Assignees: `none` Working groups: Notes: Triage: ### "Regression 1.96.1 → 1.97.0: "missing optimized MIR" for pub fn glob-reexported alongside a restricted glob duplicate" [rust#159038](https://github.com/rust-lang/rust/issues/159038) Creation date: about 20 days ago Update at: about 16 days ago Labels: [A-resolve, A-visibility, P-high, T-compiler, regression-from-stable-to-stable, C-bug, S-has-bisection] Author: `calvinrp` Assignees: `none` Working groups: Notes: Triage: ### "1.98 beta regression: "queries overflow the depth limit!"" [rust#159427](https://github.com/rust-lang/rust/issues/159427) Creation date: about 13 days ago Update at: about 9 days ago Labels: [P-high, T-compiler, regression-from-stable-to-beta, C-bug, A-async-await, S-has-mcve, S-has-bisection] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "1.98 beta regression due to name collision with `splat`" [rust#159428](https://github.com/rust-lang/rust/issues/159428) Creation date: about 13 days ago Update at: about 0 days ago Labels: [A-attributes, A-resolve, A-macros, P-high, T-compiler, regression-from-stable-to-beta, C-bug, F-splat] Author: `theemathas` Assignees: `[teor2345]` Working groups: Notes: Triage: ### "1.98 beta regression due to name collision with `unroll`" [rust#159429](https://github.com/rust-lang/rust/issues/159429) Creation date: about 13 days ago Update at: about 0 days ago Labels: [A-attributes, A-resolve, A-macros, P-high, T-compiler, regression-from-stable-to-beta, C-bug, I-lang-nominated] Author: `theemathas` Assignees: `none` Working groups: Notes: Triage: ### "EarlyOtherwiseBranch introduces access to a dead local variable" [rust#159618](https://github.com/rust-lang/rust/issues/159618) Creation date: about 9 days ago Update at: about 2 days ago Labels: [P-high, T-compiler, C-bug, A-mir-opt, I-miscompile] Author: `tmiasko` Assignees: `none` Working groups: Notes: Triage: ## P-high without a team label No issues at this time. --- ### Minutes Triage Meeting 2026 Q2 T Compiler P High Issue Review (`content/minutes/triage-meeting/2026 Q2 T-compiler P-high Issue Review.md`) --- title: T-compiler P-high issues tags: p-high-issues note_id: CQmx-X5iTO6nf23Ng5uHtA --- # 2026 Q2 T-compiler P-high Issue Review Issues snapshot collected on: 2026-06-16 ## Table of contents: - [P-high without owner](#P-high-T-compiler-issues-unassigned) (about 80) - [P-high with owner but no fix](#P-high-T-compiler-issues-with-owner-WG-or-assignee) (9) - [P-high without T-label](#All-P-high-issues-missing-a-team-label) (0) ## P-high T-compiler issues unassigned ### "Regression: Wasm32 SIMD128 narrow intrinsics stopped working correctly in Rust 1.95+" [rust#157456](https://github.com/rust-lang/rust/issues/157456) Creation date: TODO Update at: about 8 days ago Labels: [P-high, regression-from-stable-to-stable, O-wasm, A-SIMD, C-bug, llvm-fixed-upstream, I-miscompile] Author: `Cykooz` Assignees: `` Working groups: Notes: Fixed by [llvm/llvm-project#201798](https://github.com/llvm/llvm-project/pull/201798) Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604908558 ### "Performance regression (30%) between Rust 1.90 and 1.91" [rust#153154](https://github.com/rust-lang/rust/issues/153154) Creation date: TODO Update at: 2 months ago Labels: [A-LLVM, I-slow, P-high, C-bug, regression-untriaged, needs-triage] Author: `plafer` Assignees: `dianqk` Working groups: Notes: Upstream PR: [llvm/llvm-project#188740](https://github.com/llvm/llvm-project/pull/188740) (will reach downstream in one of the next LLVM updates) Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604908955 ### "disambiguate between multiple suggestions and a single multi-span suggestion; or, JSON error format is not round-trippable" [rust#53934](https://github.com/rust-lang/rust/issues/53934) Creation date: TODO Update at: 15 months ago Labels: [C-cleanup, A-diagnostics, E-mentor, P-high, T-compiler, WG-diagnostics, D-diagnostic-infra, E-needs-design] Author: `zackmdavis` Assignees: `` Working groups: Notes: maybe demote? Last triage review [was 3 years ago](https://github.com/rust-lang/rust/issues/53934#issuecomment-1355188536) and by reading the conversation it basically needs an owner. Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604909106 ### "builtin trait-object impl and user written ones can unsoundly overlap" [rust#57893](https://github.com/rust-lang/rust/issues/57893) Creation date: TODO Update at: 3 months ago Labels: [I-ICE, A-trait-system, P-high, T-lang, T-compiler, I-unsound, C-bug, S-bug-has-test, T-types, A-coherence, A-dyn-trait] Author: `arielb1` Assignees: `` Working groups: Notes: Maybe demote? #156252 seems to mitigate the soundness issue (IIUC) Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604910555 ### "Statics don't support alignments larger than the page size" [rust#70022](https://github.com/rust-lang/rust/issues/70022) Creation date: TODO Update at: 10 months ago Labels: [O-linux, P-high, T-compiler, O-windows-gnu, O-windows-msvc, I-unsound, A-target-specs, C-bug, E-needs-investigation, A-align] Author: `Amanieu` Assignees: `` Working groups: Notes: probably demote. last triaged [2 years ago](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bsteering.5D.202024-11-22.20P-high.20review/near/483932503); nothing happened since then. Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604911478 ### "'static closures/FnDefs/futures with non-'static return type are unsound" [rust#84366](https://github.com/rust-lang/rust/issues/84366) Creation date: TODO Update at: about 34 days ago Labels: [A-type-system, A-lifetimes, A-trait-system, A-closures, A-associated-items, P-high, T-lang, T-compiler, I-unsound, C-bug, A-async-await, AsyncAwait-Triaged, S-bug-has-test, T-types] Author: `steffahn` Assignees: `` Working groups: Notes: I has recent activity (it's being linked) so It should probably stay `P-high`. Seems that @_**addie.sh** is working on an unsoundness fix (#156776) that progressively grew up to include this one as well Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604912047 ### "HRTB on subtrait unsoundly provides HTRB on supertrait with weaker implied bounds" [rust#84591](https://github.com/rust-lang/rust/issues/84591) Creation date: TODO Update at: 4 months ago Labels: [A-type-system, A-lifetimes, A-trait-system, P-high, T-compiler, I-unsound, C-bug, S-bug-has-test, T-types, A-implied-bounds, A-higher-ranked] Author: `steffahn` Assignees: `` Working groups: Notes: P-high seems fine. Visited in [triage in 2021](https://github.com/rust-lang/rust/issues/84591#issuecomment-829275859), unsure about the status. Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604913824 ## XXX Triage 2026-06-19 until here ### "Compile time+memory regression between 1.49.0 and 1.50.0" [rust#84873](https://github.com/rust-lang/rust/issues/84873) Creation date: TODO Update at: 10 months ago Labels: [I-compiletime, P-high, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug] Author: `olix0r` Assignees: `` Working groups: Notes: Probably downgrade. Last [triage in 2022](https://github.com/rust-lang/rust/issues/84873#issuecomment-1320995012), seems that part of the perf. regression was recovered. It's all very old and authors didn't get back to us. Worth leaving a comment and ask to retest? ### "Compile error: static lifetime not satisfied but it is" [rust#86172](https://github.com/rust-lang/rust/issues/86172) Creation date: TODO Update at: 17 months ago Labels: [A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-async] Author: `Skepfyr` Assignees: `` Working groups: Notes: Probably downgrade: last triage [3 years ago](https://github.com/rust-lang/rust/issues/86172#issuecomment-1320194292), this [comment](https://github.com/rust-lang/rust/issues/86172#issuecomment-1553335675) indicates could be a duplicate of #71723 ### "Rustc passes syntactically invalid input to attribute macros" [rust#90256](https://github.com/rust-lang/rust/issues/90256) Creation date: TODO Update at: 38 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, WG-diagnostics, A-proc-macros] Author: `dtolnay` Assignees: `` Working groups: Notes: probably downgrade. Was triaged multiple times but no action followed up ### "rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default" [rust#95926](https://github.com/rust-lang/rust/issues/95926) Creation date: TODO Update at: 31 months ago Labels: [E-mentor, P-high, T-compiler, regression-from-stable-to-stable, E-help-wanted, O-musl, C-bug, WG-diagnostics] Author: `joshtriplett` Assignees: `` Working groups: Notes: Probably downgrade. Very old issue, last [triage 3y ago](https://github.com/rust-lang/rust/issues/95926#issuecomment-1508655129) and `musl` targets are all Tier 2. Needs an owner. ### "libcompiler-builtins contains DWARF5 debuginfo in 1.62.0" [rust#98746](https://github.com/rust-lang/rust/issues/98746) Creation date: TODO Update at: 10 months ago Labels: [A-debuginfo, E-needs-test, P-high, T-compiler, C-bug, E-needs-mcve] Author: `glandium` Assignees: `` Working groups: Notes: Maybe close as [this comment](https://github.com/rust-lang/rust/issues/98746#issuecomment-3137298203) suggest? Though as the next comment suggest, what's the status of DWARF6 in LLVM? ### "Source of lifetime coercion is not reported starting in 1.63" [rust#99256](https://github.com/rust-lang/rust/issues/99256) Creation date: TODO Update at: 41 months ago Labels: [A-diagnostics, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-diagnostics] Author: `mqudsi` Assignees: `` Working groups: Notes: maybe downgrade? That diag error is still there, I don't think we're going to fix that anytime soon ### "Codegen weirdness for `sum` of `count_ones` over an array" [rust#101060](https://github.com/rust-lang/rust/issues/101060) Creation date: TODO Update at: 30 months ago Labels: [A-LLVM, I-slow, A-codegen, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-llvm, A-autovectorization] Author: `alion02` Assignees: `` Working groups: Notes: maybe close? The last [comment](https://github.com/rust-lang/rust/issues/101060#issuecomment-1870396121) indicates that the codegen is what was expected before the regression. Tested the godbolt link and it's still the same ### "extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO" [rust#102174](https://github.com/rust-lang/rust/issues/102174) Creation date: TODO Update at: 11 months ago Labels: [A-LLVM, A-FFI, P-high, T-compiler, I-unsound, C-bug, WG-llvm, regression-untriaged, A-LTO, A-ABI, O-x86_32] Author: `glandium` Assignees: `` Working groups: Notes: ### "ld64.lld: error: too many personalities (4) for compact unwind to encode" [rust#102754](https://github.com/rust-lang/rust/issues/102754) Creation date: TODO Update at: 10 months ago Labels: [A-linkage, O-macos, O-ios, P-high, T-compiler, relnotes, regression-from-stable-to-stable, C-bug] Author: `glandium` Assignees: `` Working groups: Notes: ### "Broken compilation with `&(dyn Trait + '_)`" [rust#103762](https://github.com/rust-lang/rust/issues/103762) Creation date: TODO Update at: 19 months ago Labels: [A-resolve, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `Cerber-Ursi` Assignees: `` Working groups: Notes: ### "Miscompilation: Equal pointers comparing as unequal" [rust#107975](https://github.com/rust-lang/rust/issues/107975) Creation date: TODO Update at: 13 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, WG-llvm, I-miscompile, C-external-bug] Author: `JakobDegen` Assignees: `` Working groups: Notes: ### "`-Zdylib-lto` with ThinLTO is broken on windows-msvc" [rust#109114](https://github.com/rust-lang/rust/issues/109114) Creation date: TODO Update at: 20 months ago Labels: [A-LLVM, P-high, T-compiler, O-windows-msvc, I-unsound, WG-llvm, requires-nightly, A-LTO, I-miscompile] Author: `Noratrieb` Assignees: `` Working groups: Notes: ### "ICE: unexpected initial operand type." [rust#114858](https://github.com/rust-lang/rust/issues/114858) Creation date: TODO Update at: 8 months ago Labels: [I-ICE, P-high, T-compiler, regression-from-stable-to-stable, C-bug, E-needs-investigation] Author: `fakeshadow` Assignees: `` Working groups: Notes: ### "The ABI of float types can be changed by `-Ctarget-feature`" [rust#116344](https://github.com/rust-lang/rust/issues/116344) Creation date: TODO Update at: 11 months ago Labels: [P-high, T-compiler, I-unsound, C-tracking-issue, A-floating-point, A-ABI, A-target-feature, T-opsem] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Inlining causes miscompilation of code that mixes target features" [rust#116573](https://github.com/rust-lang/rust/issues/116573) Creation date: TODO Update at: 11 months ago Labels: [A-LLVM, A-codegen, P-high, T-compiler, I-unsound, C-bug, WG-llvm, A-target-feature, I-miscompile] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message" [rust#118099](https://github.com/rust-lang/rust/issues/118099) Creation date: TODO Update at: 31 months ago Labels: [A-LLVM, P-high, T-compiler, O-netbsd, O-PowerPC, C-bug] Author: `he32` Assignees: `` Working groups: Notes: ### "x86-64 assembler silently truncates 64-bit address" [rust#118223](https://github.com/rust-lang/rust/issues/118223) Creation date: TODO Update at: about 60 days ago Labels: [A-LLVM, O-x86_64, A-inline-assembly, P-high, T-compiler, I-unsound, C-bug, llvm-fixed-upstream, I-miscompile] Author: `MauriceKayser` Assignees: `` Working groups: Notes: ### "rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr" [rust#121124](https://github.com/rust-lang/rust/issues/121124) Creation date: TODO Update at: 7 months ago Labels: [A-LLVM, I-ICE, P-high, T-compiler, regression-from-stable-to-stable, I-unsound, O-PowerPC, C-bug, E-needs-mcve, A-LTO, O-AArch64, E-needs-investigation] Author: `bowlofeggs` Assignees: `` Working groups: Notes: ### "`-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72" [rust#125033](https://github.com/rust-lang/rust/issues/125033) Creation date: TODO Update at: 14 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, O-AArch64, A-target-feature, llvm-fixed-upstream, A-targets, I-miscompile] Author: `briansmith` Assignees: `` Working groups: Notes: ### "Undefined behavior from stack overflow on wasm32 targets" [rust#126747](https://github.com/rust-lang/rust/issues/126747) Creation date: TODO Update at: 19 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, E-needs-design] Author: `adambratschikaye` Assignees: `` Working groups: Notes: ### "Wasm32 miscompilation when using u128 with multivalue and optimizations" [rust#127318](https://github.com/rust-lang/rust/issues/127318) Creation date: TODO Update at: 19 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, O-wasm, S-has-mcve, I-miscompile, C-external-bug] Author: `arriven` Assignees: `` Working groups: Notes: ### "aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature (tracking issue for `aarch64_softfloat_neon`)" [rust#134375](https://github.com/rust-lang/rust/issues/134375) Creation date: TODO Update at: 10 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, C-tracking-issue, O-AArch64, A-ABI, A-target-feature] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Performance regression in nightly with target-cpu=native on znver4" [rust#139370](https://github.com/rust-lang/rust/issues/139370) Creation date: TODO Update at: 4 months ago Labels: [A-LLVM, I-slow, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `nsarlin-zama` Assignees: `` Working groups: Notes: ### "const-eval can construct uninhabited values or other unconstructable values out-of-thin-air via recursive static initialization" [rust#143047](https://github.com/rust-lang/rust/issues/143047) Creation date: TODO Update at: about 22 days ago Labels: [P-high, T-lang, T-compiler, I-unsound, C-bug, A-rust-for-linux, I-lang-radar] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Destructor of packed structs can move dangling references." [rust#143411](https://github.com/rust-lang/rust/issues/143411) Creation date: TODO Update at: 10 months ago Labels: [A-destructors, P-high, T-compiler, I-unsound, C-bug, T-opsem, A-repr-packed] Author: `theemathas` Assignees: `` Working groups: Notes: ### "Potentially-observable store gets elided: asm block does not act as a compiler fence" [rust#144351](https://github.com/rust-lang/rust/issues/144351) Creation date: TODO Update at: about 20 days ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "1.90 regression: Cycle detected when type checking" [rust#146813](https://github.com/rust-lang/rust/issues/146813) Creation date: TODO Update at: 8 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug, S-has-mcve, T-types, fixed-by-next-solver, I-cycle, S-has-bisection] Author: `Totodore` Assignees: `` Working groups: Notes: ### "SignatureMismatch ICE" [rust#146965](https://github.com/rust-lang/rust/issues/146965) Creation date: TODO Update at: 3 months ago Labels: [I-ICE, A-trait-system, A-associated-items, P-high, T-compiler, regression-from-stable-to-stable, C-bug, A-mir-opt, A-mir-opt-inlining, S-has-mcve, S-bug-has-test, T-types, fixed-by-next-solver] Author: `benruijl` Assignees: `` Working groups: Notes: ### "catch_unwind doesn't catch non-C++ exceptions on wasm" [rust#148273](https://github.com/rust-lang/rust/issues/148273) Creation date: TODO Update at: 4 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, T-libs, WG-ffi-unwind] Author: `bjorn3` Assignees: `` Working groups: Notes: ### "`derive(PartialEq)` on enums is unsound with user-defined attribute macros." [rust#148423](https://github.com/rust-lang/rust/issues/148423) Creation date: TODO Update at: about 57 days ago Labels: [A-macros, P-high, T-lang, T-compiler, I-unsound, C-bug, T-libs, A-proc-macros, I-lang-radar] Author: `theemathas` Assignees: `` Working groups: Notes: ### "rustc does not always update the mtime of all its outputs" [rust#148948](https://github.com/rust-lang/rust/issues/148948) Creation date: TODO Update at: 6 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "TrivialClone is not derived for generic types (Performance regression)" [rust#149752](https://github.com/rust-lang/rust/issues/149752) Creation date: TODO Update at: 2 months ago Labels: [A-macros, P-high, T-compiler, regression-from-stable-to-stable, A-specialization, C-bug, T-libs, T-types] Author: `theemathas` Assignees: `` Working groups: Notes: ### "ICE in release builds from 1.90.0 onwards" [rust#150263](https://github.com/rust-lang/rust/issues/150263) Creation date: TODO Update at: 3 months ago Labels: [I-ICE, A-trait-system, A-associated-items, P-high, T-compiler, regression-from-stable-to-stable, C-bug, A-mir-opt, A-mir-opt-inlining, S-has-mcve, S-bug-has-test, T-types, fixed-by-next-solver] Author: `zxqfd555` Assignees: `` Working groups: Notes: ### "compiler-builtins aarch64 outline atomics symbols do not work with BTI" [rust#151486](https://github.com/rust-lang/rust/issues/151486) Creation date: TODO Update at: 3 months ago Labels: [P-high, T-compiler, C-bug, T-libs, O-AArch64, A-atomic, A-target-feature] Author: `zmodem` Assignees: `` Working groups: Notes: ### "LLVM loop miscompilation" [rust#153222](https://github.com/rust-lang/rust/issues/153222) Creation date: TODO Update at: 3 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, I-miscompile] Author: `theemathas` Assignees: `` Working groups: Notes: ### "Significant compilation time regression starting in v1.95.0-nightly (bevy)" [rust#153910](https://github.com/rust-lang/rust/issues/153910) Creation date: TODO Update at: about 60 days ago Labels: [A-trait-system, I-compiletime, P-high, T-compiler, E-medium, C-bug, E-needs-mcve, T-types] Author: `gpoblon` Assignees: `` Working groups: Notes: ### "Unsoundness and ICE due to string literals that are too long for a 32-bit platform" [rust#156846](https://github.com/rust-lang/rust/issues/156846) Creation date: TODO Update at: about 13 days ago Labels: [I-ICE, P-high, T-compiler, I-unsound, C-bug, A-layout, A-str, needs-triage] Author: `theemathas` Assignees: `` Working groups: Notes: ### "Regression: unnecessary stack frame generated for arm-none-eabi targets" [rust#157163](https://github.com/rust-lang/rust/issues/157163) Creation date: TODO Update at: about 15 days ago Labels: [O-Arm, P-high, T-compiler, C-bug, I-heavy, regression-untriaged] Author: `nhpupu` Assignees: `` Working groups: Notes: ### "Performance regression since 1.93 related to MaybeUninit being wrongfully initialized" [rust#157743](https://github.com/rust-lang/rust/issues/157743) Creation date: TODO Update at: about 5 days ago Labels: [A-LLVM, P-high, T-compiler, regression-from-stable-to-stable, C-bug, llvm-fixed-upstream] Author: `glandium` Assignees: `` Working groups: Notes: ### "Statics don't support alignments larger than the page size" [rust#70022](https://github.com/rust-lang/rust/issues/70022) Creation date: TODO Update at: 10 months ago Labels: [O-linux, P-high, T-compiler, O-windows-gnu, O-windows-msvc, I-unsound, A-target-specs, C-bug, E-needs-investigation, A-align] Author: `Amanieu` Assignees: `` Working groups: Notes: maybe downgrade at this point? [triaged again in 2024](https://github.com/rust-lang/rust/issues/70022#issuecomment-2494019524) ### "Compile time+memory regression between 1.49.0 and 1.50.0" [rust#84873](https://github.com/rust-lang/rust/issues/84873) Creation date: TODO Update at: 10 months ago Labels: [I-compiletime, P-high, T-compiler, regression-from-stable-to-stable, I-compilemem, C-bug] Author: `olix0r` Assignees: `` Working groups: Notes: part of the regression war recovered (see [comment](https://github.com/rust-lang/rust/issues/84873#issuecomment-1320995012)) ### "Compile error: static lifetime not satisfied but it is" [rust#86172](https://github.com/rust-lang/rust/issues/86172) Creation date: TODO Update at: 17 months ago Labels: [A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-async] Author: `Skepfyr` Assignees: `` Working groups: Notes: ### "Rustc passes syntactically invalid input to attribute macros" [rust#90256](https://github.com/rust-lang/rust/issues/90256) Creation date: TODO Update at: 38 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, WG-diagnostics, A-proc-macros] Author: `dtolnay` Assignees: `` Working groups: Notes: ### "rustc 1.59/1.60 builds musl binaries that segfault, when compiling with musl-gcc wrappers, due to static-pie default" [rust#95926](https://github.com/rust-lang/rust/issues/95926) Creation date: TODO Update at: 31 months ago Labels: [E-mentor, P-high, T-compiler, regression-from-stable-to-stable, E-help-wanted, O-musl, C-bug, WG-diagnostics] Author: `joshtriplett` Assignees: `` Working groups: Notes: ### "libcompiler-builtins contains DWARF5 debuginfo in 1.62.0" [rust#98746](https://github.com/rust-lang/rust/issues/98746) Creation date: TODO Update at: 10 months ago Labels: [A-debuginfo, E-needs-test, P-high, T-compiler, C-bug, E-needs-mcve] Author: `glandium` Assignees: `` Working groups: Notes: ### "Source of lifetime coercion is not reported starting in 1.63" [rust#99256](https://github.com/rust-lang/rust/issues/99256) Creation date: TODO Update at: 41 months ago Labels: [A-diagnostics, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-diagnostics] Author: `mqudsi` Assignees: `` Working groups: Notes: ### "Codegen weirdness for `sum` of `count_ones` over an array" [rust#101060](https://github.com/rust-lang/rust/issues/101060) Creation date: TODO Update at: 30 months ago Labels: [A-LLVM, I-slow, A-codegen, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug, WG-llvm, A-autovectorization] Author: `alion02` Assignees: `` Working groups: Notes: ### "extern "C" functions don't generate the same IR definitions as clang on x86, causing problems with cross-language LTO" [rust#102174](https://github.com/rust-lang/rust/issues/102174) Creation date: TODO Update at: 11 months ago Labels: [A-LLVM, A-FFI, P-high, T-compiler, I-unsound, C-bug, WG-llvm, regression-untriaged, A-LTO, A-ABI, O-x86_32] Author: `glandium` Assignees: `` Working groups: Notes: ### "ld64.lld: error: too many personalities (4) for compact unwind to encode" [rust#102754](https://github.com/rust-lang/rust/issues/102754) Creation date: TODO Update at: 10 months ago Labels: [A-linkage, O-macos, O-ios, P-high, T-compiler, relnotes, regression-from-stable-to-stable, C-bug] Author: `glandium` Assignees: `` Working groups: Notes: ### "Broken compilation with `&(dyn Trait + '_)`" [rust#103762](https://github.com/rust-lang/rust/issues/103762) Creation date: TODO Update at: 19 months ago Labels: [A-resolve, A-lifetimes, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `Cerber-Ursi` Assignees: `` Working groups: Notes: ### "Miscompilation: Equal pointers comparing as unequal" [rust#107975](https://github.com/rust-lang/rust/issues/107975) Creation date: TODO Update at: 13 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, WG-llvm, I-miscompile, C-external-bug] Author: `JakobDegen` Assignees: `` Working groups: Notes: ### "`-Zdylib-lto` with ThinLTO is broken on windows-msvc" [rust#109114](https://github.com/rust-lang/rust/issues/109114) Creation date: TODO Update at: 20 months ago Labels: [A-LLVM, P-high, T-compiler, O-windows-msvc, I-unsound, WG-llvm, requires-nightly, A-LTO, I-miscompile] Author: `Noratrieb` Assignees: `` Working groups: Notes: ### "Inlining causes miscompilation of code that mixes target features" [rust#116573](https://github.com/rust-lang/rust/issues/116573) Creation date: TODO Update at: 11 months ago Labels: [A-LLVM, A-codegen, P-high, T-compiler, I-unsound, C-bug, WG-llvm, A-target-feature, I-miscompile] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message" [rust#118099](https://github.com/rust-lang/rust/issues/118099) Creation date: TODO Update at: 31 months ago Labels: [A-LLVM, P-high, T-compiler, O-netbsd, O-PowerPC, C-bug] Author: `he32` Assignees: `` Working groups: Notes: ### "x86-64 assembler silently truncates 64-bit address" [rust#118223](https://github.com/rust-lang/rust/issues/118223) Creation date: TODO Update at: about 60 days ago Labels: [A-LLVM, O-x86_64, A-inline-assembly, P-high, T-compiler, I-unsound, C-bug, llvm-fixed-upstream, I-miscompile] Author: `MauriceKayser` Assignees: `` Working groups: Notes: ### "rust-1.75.0 fails to compile with ICE on aarch64 and various ppc arches with LTO enabled - error: could not compile memchr" [rust#121124](https://github.com/rust-lang/rust/issues/121124) Creation date: TODO Update at: 7 months ago Labels: [A-LLVM, I-ICE, P-high, T-compiler, regression-from-stable-to-stable, I-unsound, O-PowerPC, C-bug, E-needs-mcve, A-LTO, O-AArch64, E-needs-investigation] Author: `bowlofeggs` Assignees: `` Working groups: Notes: ### "`-C target_cpu=cortex-a72` (and `-target-cpu=native` on Raspberry Pi) wrongly enables crypto features that are optional on Cortex-A72" [rust#125033](https://github.com/rust-lang/rust/issues/125033) Creation date: TODO Update at: 14 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, O-AArch64, A-target-feature, llvm-fixed-upstream, A-targets, I-miscompile] Author: `briansmith` Assignees: `` Working groups: Notes: ### "Undefined behavior from stack overflow on wasm32 targets" [rust#126747](https://github.com/rust-lang/rust/issues/126747) Creation date: TODO Update at: 19 months ago Labels: [P-high, T-compiler, I-unsound, O-wasm, C-bug, E-needs-design] Author: `adambratschikaye` Assignees: `` Working groups: Notes: ### "Wasm32 miscompilation when using u128 with multivalue and optimizations" [rust#127318](https://github.com/rust-lang/rust/issues/127318) Creation date: TODO Update at: 19 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, O-wasm, S-has-mcve, I-miscompile, C-external-bug] Author: `arriven` Assignees: `` Working groups: Notes: ### "Hang after encountering overflow errors for huge types " [rust#132673](https://github.com/rust-lang/rust/issues/132673) Creation date: TODO Update at: about 28 days ago Labels: [A-diagnostics, P-high, T-compiler, regression-from-stable-to-stable, C-bug, I-hang, S-has-mcve] Author: `ym-xie` Assignees: `` Working groups: Notes: ### "aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature (tracking issue for `aarch64_softfloat_neon`)" [rust#134375](https://github.com/rust-lang/rust/issues/134375) Creation date: TODO Update at: 10 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, C-tracking-issue, O-AArch64, A-ABI, A-target-feature] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "Performance regression in nightly with target-cpu=native on znver4" [rust#139370](https://github.com/rust-lang/rust/issues/139370) Creation date: TODO Update at: 4 months ago Labels: [A-LLVM, I-slow, O-x86_64, P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `nsarlin-zama` Assignees: `` Working groups: Notes: ### "ICE: unexpected initial operand type." [rust#114858](https://github.com/rust-lang/rust/issues/114858) Creation date: TODO Update at: 8 months ago Labels: [I-ICE, P-high, T-compiler, regression-from-stable-to-stable, C-bug, E-needs-investigation] Author: `fakeshadow` Assignees: `` Working groups: Notes: ### "Potentially-observable store gets elided: asm block does not act as a compiler fence" [rust#144351](https://github.com/rust-lang/rust/issues/144351) Creation date: TODO Update at: about 20 days ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "rustc does not always update the mtime of all its outputs" [rust#148948](https://github.com/rust-lang/rust/issues/148948) Creation date: TODO Update at: 6 months ago Labels: [P-high, T-compiler, regression-from-stable-to-stable, C-bug] Author: `RalfJung` Assignees: `` Working groups: Notes: ### "LLVM loop miscompilation" [rust#153222](https://github.com/rust-lang/rust/issues/153222) Creation date: TODO Update at: 3 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, I-miscompile] Author: `theemathas` Assignees: `` Working groups: Notes: ### "Unsoundness and ICE due to string literals that are too long for a 32-bit platform" [rust#156846](https://github.com/rust-lang/rust/issues/156846) Creation date: TODO Update at: about 13 days ago Labels: [I-ICE, P-high, T-compiler, I-unsound, C-bug, A-layout, A-str, needs-triage] Author: `theemathas` Assignees: `` Working groups: Notes: ### "Regression: unnecessary stack frame generated for arm-none-eabi targets" [rust#157163](https://github.com/rust-lang/rust/issues/157163) Creation date: TODO Update at: about 15 days ago Labels: [O-Arm, P-high, T-compiler, C-bug, I-heavy, regression-untriaged] Author: `nhpupu` Assignees: `` Working groups: Notes: ### "Performance regression since 1.93 related to MaybeUninit being wrongfully initialized" [rust#157743](https://github.com/rust-lang/rust/issues/157743) Creation date: TODO Update at: about 5 days ago Labels: [A-LLVM, P-high, T-compiler, regression-from-stable-to-stable, C-bug, llvm-fixed-upstream] Author: `glandium` Assignees: `` Working groups: Notes: ## P-high T-compiler issues with owner (WG or assignee) ### "Varargs are completely unchecked if passed as generics" [rust#61275](https://github.com/rust-lang/rust/issues/61275) Creation date: TODO Update at: 3 months ago Labels: [A-FFI, P-high, T-compiler, I-unsound, S-has-mcve, I-miscompile] Author: `joshuabogue` Assignees: `workingjubilee` Working groups: Notes: feels can stay P-high. Now we have PR #155697 that should clarify how c-varargs in FFI (IIUC) Triage: [leaving as it is](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604898758) Meeting notes: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604898758 ### "Switching to opt-level=z on i686-windows-msvc triggers STATUS_ACCESS_VIOLATION" [rust#67497](https://github.com/rust-lang/rust/issues/67497) Creation date: TODO Update at: 19 months ago Labels: [A-LLVM, O-windows, P-high, T-compiler, I-unsound, C-bug, E-needs-mcve, O-x86_32, E-needs-investigation] Author: `dignifiedquire` Assignees: `wesleywiser` Working groups: Notes: Maybe downgrade? [Triaged again in 2024](https://github.com/rust-lang/rust/issues/67497#issuecomment-2494000870) but no feedback from the reporter. Ask again the authors? Meeting notes: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604899833 ### "Locals aligned to greater than page size can cause unsound behavior" [rust#70143](https://github.com/rust-lang/rust/issues/70143) Creation date: TODO Update at: 13 months ago Labels: [A-LLVM, O-windows, P-high, T-compiler, I-unsound, C-bug, C-external-bug] Author: `retep998` Assignees: `cuviper` Working groups: Notes: unsure about priority. [triaged in 2024](https://github.com/rust-lang/rust/issues/70143#issuecomment-2494035002), nothing since then. needs investigation. Maybe ping wg-llvm again? Meeting notes: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604900802 ### "Error reporting from attribute macros regressed in 1.46.0" [rust#76360](https://github.com/rust-lang/rust/issues/76360) Creation date: TODO Update at: 13 months ago Labels: [A-diagnostics, P-high, T-compiler, regression-from-stable-to-stable, WG-diagnostics, A-proc-macros] Author: `ahl` Assignees: `estebank` Working groups: Notes: needs investigation from WG-diagnostics (unsure how busy they are, cc @**davidtwco**) Meeting notes: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604901361 ### "Passing `-C panic=abort` still attempts to link in `libunwind` when targeting `i686-pc-windows-gnu` on `v1.44+`" [rust#79609](https://github.com/rust-lang/rust/issues/79609) Creation date: TODO Update at: 18 months ago Labels: [A-runtime, A-linkage, O-windows, A-cross, P-high, T-compiler, regression-from-stable-to-stable, C-bug, O-x86_32] Author: `staticfloat` Assignees: `wesleywiser` Working groups: Notes: Maybe downgrade? Given the target (`i686-pc-windows-gnu`) and old rustc version it started (1.44)? Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604901927 ### "LLVM miscompiles large stack allocations" [rust#100914](https://github.com/rust-lang/rust/issues/100914) Creation date: TODO Update at: 19 months ago Labels: [A-LLVM, P-high, T-compiler, I-unsound, C-bug, WG-llvm, I-miscompile] Author: `Cl00e9ment` Assignees: `wesleywiser` Working groups: Notes: unless I am mistaken, the original repro does not error anymore (exit with 0). Could this one be fixed at some point? Maybe ping wg-llvm again? Triaged: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604903269 ### "miscompilation with incremental + unpacked debug + macos " [rust#108216](https://github.com/rust-lang/rust/issues/108216) Creation date: TODO Update at: 3 months ago Labels: [O-macos, P-high, T-compiler, regression-from-stable-to-stable, I-unsound, A-incr-comp, C-bug] Author: `ehuss` Assignees: `lqd` Working groups: Notes: Probably still a P-high, seems it needs a repro and someone familiar with incr-comp intricacies (cc @**lqd** wdyt?) Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604903940 ### "mutable_transmutes lint should catch transmutes from a type without interior mutability to one with" [rust#111229](https://github.com/rust-lang/rust/issues/111229) Creation date: TODO Update at: 18 months ago Labels: [A-LLVM, A-lints, P-high, T-compiler, C-bug] Author: `glandium` Assignees: `ChayimFriedman2` Working groups: Notes: There is another tentative fix in #143343, maybe ping author again? Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604904984 ### "`lemmy_db_views_modlog_combined` has a weird performance regression" [rust#141006](https://github.com/rust-lang/rust/issues/141006) Creation date: TODO Update at: 8 months ago Labels: [I-compiletime, P-high, T-compiler, C-bug, E-needs-mcve, regression-untriaged] Author: `lcnr` Assignees: `steffahn` Working groups: Notes: probably good to keep at P-high for a bit more. Needs a reproducible. Seems that @**Frank Steffahn** wanted to look into it Triage: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Btriage.5D.202026-06-19.20P-high.20review/near/604906529 ## All P-high issues missing a team label None --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 03 12 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-03-12.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-03-12 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements * [Planning meeting](https://forge.rust-lang.org/compiler/steering-meeting.html) tomorrow (March 13th) * Rust 1.42 is released today ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) * Use TypeRelating for instantiating query responses [#69591][] :back: / :hand: [#69591]: https://github.com/rust-lang/rust/pull/69591 ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) No PR's S-waiting-on-team this time. ## Issues of Note - [52 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) and [32 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [2 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - [3 P-high and 1 P-medium regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [ ] "Compiler incorrectly assumes int will never be one" [#69841][] - [ ] "ICE in collect_and_partition_mono_items" [#69785][] - [ ] "ICE: src/librustc/middle/region.rs:1037: Encountered greater count 28" [#69307][] - [ ] "Replace our fragile safety scheme around erroneous constants" [#67191][] - [ ] "ICE field: higher-rank trait bound (HRTB) `for<'a> ...` hits OutputTypeParameterMismatch in librustc/traits/codegen" [#62529][] [#69841]: https://github.com/rust-lang/rust/issues/69841 [#69785]: https://github.com/rust-lang/rust/issues/69785 [#69307]: https://github.com/rust-lang/rust/issues/69307 [#67191]: https://github.com/rust-lang/rust/issues/67191 [#62529]: https://github.com/rust-lang/rust/issues/62529 ## WG checkins WG-nll: nothing to share and the wg should be removed from the rotation. WG-parallel-rustc: no updates. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 03 19 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-03-19.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-03-19 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - We are in the process of forming a WG-prioritization working group. - Focus: mainly on deciding if bugs are critical (potential release blockers) or not. - There's a [new WG-prioritization stream](https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization) where pre-triage is going to happen from now on. - [Poll] Should we remove I-nominated on toolstate breakage issues?. ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - can_begin_literal_or_bool: `true` on `"-"? lit` NTs. [#70058](https://github.com/rust-lang/rust/pull/70058) :back: / :hand: Already beta accepted ... - Use TypeRelating for instantiating query responses [#69591](https://github.com/rust-lang/rust/pull/69591) ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) No PR's S-waiting-on-team this time. ## Issues of Note - [54 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) and [32 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [1 P-high and 4 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - [5 P-high and 1 P-medium regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [ ] "rustc segfault" [#70117](https://github.com/rust-lang/rust/issues/70117) - [ ] "ICE using associated type from higher ranked trait" [#70120](https://github.com/rust-lang/rust/issues/70120) ## WG checkins WG-PGO: working group is retired. WG-pipelining: working group is disbanded. We should remove both from rotation, also nll and probably check the status of all the working groups. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 03 26 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-03-26.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-03-26 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - As per last week discussion, we are going to stop tagging as I-nominated on toolstate breakage [#70407](https://github.com/rust-lang/rust/pull/70407) - Please check if the conclusion stated on Santiago's comment there is what we want. ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Fix smaller issues with invalid placeholder type errors" [#70369] :back: / :hand: / :shrug: - "Account for bad placeholder types in where clauses" [#70294] :back: / :hand: / :shrug: - "Fix ICE caused by truncating a negative ZST enum discriminant" [#70126] :back: / :hand: / :shrug: - "Ensure HAS_FREE_LOCAL_NAMES is set for ReFree" [#69956] :back: / :hand: / :shrug: [#70369]: https://github.com/rust-lang/rust/pull/70369 [#70294]: https://github.com/rust-lang/rust/pull/70294 [#70126]: https://github.com/rust-lang/rust/pull/70126 [#69956]: https://github.com/rust-lang/rust/pull/69956 ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. :tada: ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) No PR’s S-waiting-on-team this time. :tada: ## P-high Issues of Note - [50 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (4 less than last week) - [30 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (2 less than last week) - [3 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - [1 P-high and 3 P-medium regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [x] "Compiler incorrectly assumes int will never be one" [#69841](https://github.com/rust-lang/rust/issues/69841) - [ ] "Add cryptographic hash of source files in debug info" [#69718](https://github.com/rust-lang/rust/pull/69718) - [ ] "Box doesn't respect self alignment" [#68304](https://github.com/rust-lang/rust/pull/68304) ## WG checkins WG-learning and WG-LLVM. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 04 02 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-04-02.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-04-02 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Do we agree on adding an `I-prioritize` like label? - So we can have I-nominated for let's discuss this and I-prioritize as a request for prioritization. - Should it be `I-prioritize`, `P-prioritize` or maybe `WG-prioritization`?. - Tomorrow: Design meeting: cranelift backend for rustc ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Fix "since" field for `Once::is_complete`'s `#[stable]` attribute" [#70018](https://github.com/rust-lang/rust/pull/70018) :back: / :hand: - "parse_and_disallow_postfix_after_cast: account for `ExprKind::Err`." [#70556](https://github.com/rust-lang/rust/pull/70556) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) - "Remove -Z no-landing-pads flag" [#70175](https://github.com/rust-lang/rust/pull/70175) - FCPed 2 days ago with 8 :+1: out of 13 - In disposition-merge state ## Issues of Note - [51 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (1 more than last week) - [28 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (2 less than last week) - [2 P-high and 2 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - [2 P-high and 4 P-medium regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) ### Unassigned stable to beta regressions - "no_mangle causes compilation errors with async-await on armv7-linux-androideabi and aarch64-linux-android targets" [#70098](https://github.com/rust-lang/rust/issues/70098) ### Unassigned stable to nightly regressions - "internal compiler error: cannot relate region: LUB(ReErased, ReErased)" [#70608](https://github.com/rust-lang/rust/issues/70608) - This one is nominated anyway. - "Some macro errors now include file names into the standard library (JSON)." [#70396](https://github.com/rust-lang/rust/issues/70396) - "file not found for module" [#70314](https://github.com/rust-lang/rust/issues/70314) - "Regression in error message quality for macro_rules involving $:ident" [#69604](https://github.com/rust-lang/rust/issues/69604) - "Compiler error while compiling Winrt" [#66402](https://github.com/rust-lang/rust/issues/66402) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [ ] "Box doesn't respect self alignment" [#68304](https://github.com/rust-lang/rust/issues/68304) - [ ] "internal compiler error: cannot relate region: LUB(ReErased, ReErased)" [#70608](https://github.com/rust-lang/rust/issues/70608) - [ ] "regression: assertion failed: data.is_empty()" [#70445](https://github.com/rust-lang/rust/issues/70445) - [ ] "internal compiler error: no type for local variable" [#70594](https://github.com/rust-lang/rust/issues/70594) - [ ] "Should enum discriminants have generics in scope?" [#70453](https://github.com/rust-lang/rust/issues/70453) ## WG checkins WG-Meta: WG-MIR-Opt: --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 04 09 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-04-09.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-04-09 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Tomorrow we have our [planning meeting](https://forge.rust-lang.org/compiler/steering-meeting.html) - WG-prioritization has created two labels - `I-prioritize` so we can ask for prioritization using that label and leave `I-nominated` to nominate issues for discussion. [Read the thread for more info](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/I-nominated.20vs.20I-prioritize) - `P-critical`, this will be critical priority issues. We are in the process of documenting our scheme properly but use your judgement and more or less the idea of a critical bug is one that potentially blocks a release. ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "macro_rules: `NtLifetime` cannot start with an identifier" [#70768](https://github.com/rust-lang/rust/issues/70768) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) - Fix staticlib name for *-pc-windows-gnu targets [#70937](https://github.com/rust-lang/rust/pull/70937) - Needs a decision that we want to go ahead with this fix. - A big options clean-up [#70729](https://github.com/rust-lang/rust/pull/70729) (also in `Nominated Issues` list) - Waiting on @estebank, @matthewjasper, @nagisa and @pnkfelix to check their boxes or provide concerns. - Move LLVM bitcode destination [#70458](https://github.com/rust-lang/rust/pull/70458) - Waiting on final comment period to elapse. - Remove -Z no-landing-pads flag [#70175](https://github.com/rust-lang/rust/pull/70175) - Waiting on final comment period to elapse. - Add Option to Force Unwind Tables [#69984](https://github.com/rust-lang/rust/pull/69984) - Waiting on @Zoxc, @cramertj and @pnkfelix to check their boses or provide concerns. - Add error codes duplicates check [#68639](https://github.com/rust-lang/rust/pull/68639) - Waiting on something from `wg-diagnostics`? - Ensure all iterations in Rayon iterators run in the presence of panics [#68171](https://github.com/rust-lang/rust/pull/68171) - Needs a decision that we want to go ahead with this change (possibly from `wg-parallel-rustc`). ## Issues of Note - [0 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) and [0 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) - [49 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (2 less than last week) - [27 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (1 less than last week) - [1 P-high and 3 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - [3 P-high, 3 P-medium, 3 from T-rustdoc regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [ ] "Compile regression "cannot infer an appropriate lifetime for lifetime parameter"" [#70917](https://github.com/rust-lang/rust/issues/70917) - [ ] "PhantomData no longer dropck?" [#70841](https://github.com/rust-lang/rust/issues/70841) - [ ] "A big options clean-up" [#70729](https://github.com/rust-lang/rust/pull/70729) (also in `PR's S-waiting-on-team` list) - [ ] "ICEs should always print the top of the query stack." [#70953](https://github.com/rust-lang/rust/issues/70953) - [ ] "[WIP] Rename mir::Rvalue to Op." [#70928](https://github.com/rust-lang/rust/pull/70928) - [ ] "WIP toward LLVM Code Coverage for Rust" [#70680](https://github.com/rust-lang/rust/pull/70680) - [ ] "Use the niche optimization if other variant are small enough" [#70477](https://github.com/rust-lang/rust/pull/70477) ## WG checkins WG-Rustc-Dev-Guide and WG-LLVM. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 04 16 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-04-16.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-04-16 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Next Thursday, April 23rd we are releasing 1.43 - [MCP RFC is pending](https://github.com/rust-lang/rfcs/pull/2904) - Automate compiler development [#272](https://github.com/rust-lang/compiler-team/issues/272) - We have `@rustbot seconded` support ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Do not reuse post LTO products when exports change" [#71131](https://github.com/rust-lang/rust/pull/71131) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) - "Add Option to Force Unwind Tables" [#69984](https://github.com/rust-lang/rust/pull/69984) - In FCP, Disposition to merge. - "A big options clean-up" [#70729](https://github.com/rust-lang/rust/pull/70729) - In FCP, disposition to merge. - "Remove -Z no-landing-pads flag" [#70175](https://github.com/rust-lang/rust/pull/70175) - FCP finished, disposition to merge. - "Move LLVM bitcode destination" [#70458](https://github.com/rust-lang/rust/pull/70458) - FCP finished, disposition to merge and needs a reviewer. ## Issues of Note - [1 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) (1 more than last week) - [45 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (4 less than last week) - [26 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (1 less than last week) - [2 P-high and 2 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - The 2 P-medium are unassigned - [2 P-high, 2 P-medium and 1 T-rustdoc regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - All of them are unassigned ### P-critical - "`static FOO:Foo=FOO;` doesn't cause cycle error for zero-sized-type with no public constructor." [#71078](https://github.com/rust-lang/rust/pull/71078) - This issue is assigned to @oli ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - [ ] "[WIP] Rename mir::Rvalue to Op." [#70928](https://github.com/rust-lang/rust/issues/70928) - In FCP, disposition to close. - [ ] "Should enum discriminants have generics in scope?" [#70453](https://github.com/rust-lang/rust/issues/70453) - In FCP, disposition to merge. - [ ] "Add support for parsing with rust-analyzer instead of librustc_parse #70761" [#70761](https://github.com/rust-lang/rust/pull/70761) - Nominated for discussion, maybe needs an MCP. ## WG checkins WG-meta: let's check with @nikomatsakis to see if he wants to mention something but we had a checkin recently. WG-Mir-Opt: Mir Opt skips this time. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 04 23 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-04-23.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-04-23 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Today we are releasing Rust 1.43.0 - Tomorrow (Friday) we will have a compiler team meeting about ["Standard library implementation ownership" #267](https://github.com/rust-lang/compiler-team/issues/267) - There are 5 major changes proposals - [Decentralize queries #277](https://github.com/rust-lang/compiler-team/issues/277) - [Major change proposal: Support collecting all identifiers encountered during compilation #276](https://github.com/rust-lang/compiler-team/issues/276) - [Move `src/test/run-fail` tests to UI #274](https://github.com/rust-lang/compiler-team/issues/274) - [Integration of the Cranelift backend with rustc #270](https://github.com/rust-lang/compiler-team/issues/270) - [[major change] MIR librarification #233](https://github.com/rust-lang/compiler-team/issues/233) ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "[beta] fix failing const validation" [#71441](https://github.com/rust-lang/rust/pull/71441) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) - "Add Option to Force Unwind Tables" [#69984](https://github.com/rust-lang/rust/pull/69984) - FCP finished, disposition to merge. - "Remove -Z no-landing-pads flag" [#70175](https://github.com/rust-lang/rust/pull/70175) - FCP finished, disposition to merge. ## Issues of Note ### Short Summary - [1 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) (same as last week) - [43 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (2 less than last week) - [22 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (4 less than last week) - [1 P-high, 2 P-medium, 1 P-low, 2 T-libs and 1 T-rustdoc regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - The only assigned is the P-high one. One of the T-libs and the T-rustdoc are unassigned. - [3 P-high, 3 P-medium, 1 P-low and 1 T-libs regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - Only 2 P-high are assigned. - [69 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [24 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). ### P-critical - "`static FOO:Foo=FOO;` doesn't cause cycle error for zero-sized-type with no public constructor." [#71078](https://github.com/rust-lang/rust/pull/71078) - This issue is assigned to @oli - This is `P-critical` but is not going to be included in 1.43.0. `P-critical` means that it potentially blocks the release and this time it didn't block it. - Should this one be beta-nominated after the nightly to beta promotion happens? (If PR #71078 lands before promotion then point is moot.) ### Unassigned P-high regressions - "`broken MIR` `NoSolution` sized array initialiser with addition in generic tuple destructure" [#71344](https://github.com/rust-lang/rust/issues/71344) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - "`unsized_locals` fails to uphold alignment requirements" [#71416](https://github.com/rust-lang/rust/issues/71416) - We need to discuss about a possible solution for this one. - "Debuginfo tests are not running" [#47163](https://github.com/rust-lang/rust/issues/47163) - According to @jonas-schievink, we have not been able to run these tests for over 2 years. There are some PRs by @tromey. It's not clear if [#71428](https://github.com/rust-lang/rust/pull/71428) fixes this problem entirely or partially. - "Rename mir::Rvalue to Op." [#70928](https://github.com/rust-lang/rust/pull/70928) - We discussed this one last week. It would be good to mention that the discussion keeps going and Zulip may be a good place for it. ## WG checkins WG-parallel-rustc: @simulacrum mentioned that there are no updates. WG-polonius: @lqd shared [this](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202020-04-23.20.2354818/near/194978584). --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 04 30 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-04-30.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-04-30 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - There are 3 major changes proposals - Implement LLVM-compatible source-based code coverage [#278](https://github.com/rust-lang/compiler-team/issues/278) - illumos toolchain builds [#279](https://github.com/rust-lang/compiler-team/issues/279) - Inline assembly [#280](https://github.com/rust-lang/compiler-team/issues/280) ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Quick and dirty fix of the unused_braces lint" [#71517](https://github.com/rust-lang/rust/pull/71517) :back: / :hand: - "normalize field projection ty to fix broken MIR issue" [#71488](https://github.com/rust-lang/rust/pull/71488) :back: / :hand: - "fix error code in E0751.md" [#71426](https://github.com/rust-lang/rust/pull/71426) :back: / :hand: - "Remove some `Vec` allocations to improve performance" [#71268](https://github.com/rust-lang/rust/pull/71268) :back: / :hand: T-libs ones ... - "Update stdarch submodule" [#71495](https://github.com/rust-lang/rust/pull/71495) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. T-libs ones ... - "Update stdarch submodule" [#71495](https://github.com/rust-lang/rust/pull/71495) :back: / :hand: - "avx512 support regression in 1.43" [#71473](https://github.com/rust-lang/rust/issues/71473) :back: / :hand: ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) - "Add Option to Force Unwind Tables" [#69984](https://github.com/rust-lang/rust/pull/69984) - FCP finished, disposition to merge. ## Issues of Note ### Short Summary - [2 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) (one more than last week) - [both are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) (one more than last week) - [42 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) (one less than last week) - [21 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) (one less than last week) - [1 P-high, 2 P-medium, 1 P-low, 1 T-libs regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - The only assigned is the P-high one. - [2 P-high, 3 P-medium, 2 P-low regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - Both P-high are assigned and one P-low is assigned too. - [71 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [25 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). There are 1 more `P-critical` issue and 1 less `P-high` issues in comparison with last week. ### P-critical - "rust-analyser segfault with lto=thin, linker=lld-link" [#71504](https://github.com/rust-lang/rust/issues/71504) - Unassigned. - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - Unassigned. ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - This is a very bad issue, already listed as P-critical - ~~"`unsized_locals` fails to uphold alignment requirements" [#71416](https://github.com/rust-lang/rust/issues/71416)~~ - (@pnkfelix opened some fresh sub-issues.) ## WG checkins WG-Polymorphization by @davidtwco: > I can't remember where the polymorphisation work was last time I gave an update at the meeting, so to remind everyone, the polymorphisation working group is for tracking my master's project - implementing an analysis that will detect when generic parameters are unused, and then reducing monomorphisation as a result. > > #69749 has a working implementation of polymorphisation (I've paused working on it until my exams are over), which we've run perf on and gotten mixed results - there are some interesting interactions with LTO on one benchmark configuration, and some cases see 3-5% improvements, but some are worse-off (normally by 1-2%). There's probably some room for improvement yet. WG-prioritization by @spastorino: This is the first checkin from WG Prioritization. - [The group is formally formed](https://rust-lang.github.io/compiler-team/working-groups/prioritization/) - Main goal is to triaging bugs, mainly deciding if bugs are critical (potential release blockers) or not. - Route bugs to folks who can fix them. - Build the agenda for these meetings. - Among other things :) - We have [some plans](https://hackmd.io/P3yvagSSS7yAI2QxhLfPtQ?view) and [procedures](https://hackmd.io/pHb6eTZ2Sjy6XZmwXZHIBA?view) documented. - We've created I-prioritize and splitted the meaning of it with I-nominated for easier request for prioritization. - We've created P-critical and defined the [different priority levels](https://hackmd.io/7NRRbq62TnaezW7-n15cDw) this is still WIP. - We're trying to have all this process async - When someone tags `I-prioritize` a Zulip topic is automatically created requesting for prioritization of the issue in question so we can prioritize async. - @rustbot prioritize works too for non-members - We should do the same for beta/stable backports, I-nominated, S-waiting-on-team - We're also trying to automate with commands our meetings and this one in particular. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 05 07 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-05-07.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-05-07 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Today we are making a point release, 1.43.1 :tada: - Remember to fill State of the Compiler Team form by end of today (Thursday). Niko and Felix need time to review before Friday's steering meeting. (You should have links to separate non-anonymous and anonymized feedback forms in your email.) - On friday we have our [Compiler Team Planning meeting](https://forge.rust-lang.org/compiler/steering-meeting.html). - There is 1 major change proposal - "intern predicates, introduce forall/implies" [#285](https://github.com/rust-lang/compiler-team/issues/285) ## Beta-acceptances from past week - "fix error code in E0751.md" [#71426](https://github.com/rust-lang/rust/pull/71426) was unlaterally beta-accepted by @pnkfelix - "resolve: Relax fresh binding disambiguation slightly to fix regression" [#71846](https://github.com/rust-lang/rust/pull/71846) was unilaterally beta-accepted by @pnkfelix - "Do not try to find binop method on RHS `TyErr`" [#71810](https://github.com/rust-lang/rust/pull/71810) was unilaterally beta-accepted by @pnkfelix ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Update the `cc` crate" [#71882](https://github.com/rust-lang/rust/pull/71882) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) No PR's waiting on team this time. ## Issues of Note ### Short Summary - [1 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) - [0 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) - [40 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) - [20 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [1 P-high, 4 P-medium, 1 P-low regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - The only assigned is the P-high one. - [1 P-high, 3 P-medium, 1 P-low regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - The only assigned is the P-high one. - [69 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [24 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). There are 1 less `P-critical` issues and 2 less `P-high` issues in comparison with last week. ### P-critical - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - This issue is assigned to @spastorino and has a PR open. ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - "Rustc overflow its stack when using impl Trait and the struct containing the function itself" [#69096](https://github.com/rust-lang/rust/issues/69096) - "rust-lld since 1.38 overlaps .text with .rodata for embedded arm target" [#65391](https://github.com/rust-lang/rust/issues/65391) - "Compile-time stack overflow when trait impl contains extern crate" [#55779](https://github.com/rust-lang/rust/issues/55779) - ~~"repr(packed) allows invalid unaligned loads" [#27060](https://github.com/rust-lang/rust/issues/27060)~~ (pnkfelix added by accident) ## WG checkins @**WG-rls2.0** checkin by @**matklad**: > Checkin text @**WG-self-profile** checkin by @**Wesley Wiser**: Things have settled down quite a lot since the last check-in. We achieved our MVP goal and since then, lots of people have been using the tools either directly or via the perf.rlo integration. I think the only major news is that we have documentation everwhere that has been requested: * GitHub readme files for each individual tool. * `rustc -Zhelp` has some short help text describing the options. * The Unstable Book has [more complete](https://doc.rust-lang.org/unstable-book/compiler-flags/self-profile.html) documentation about the `-Z` flags. * Rustc Dev Guide has a [mention](https://rustc-dev-guide.rust-lang.org/profiling.html). I also wrote a rather extensive post on the [Inside-Rust blog](https://blog.rust-lang.org/inside-rust/2020/02/25/intro-rustc-self-profile.html) about the tooling including a complete step-by-step tutorial. While there additional polish that could be done, there are no remaining "must-have" features that I'm aware of. --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 05 14 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-05-14.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-05-14 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - We have a design meeting tomorrow: "survey overview and discussion" - Major Changes Proposals: - Seconded proposals (in FCP) - "Implement LLVM-compatible source-based code coverage" [#278](https://github.com/rust-lang/compiler-team/issues/278) - "Inline assembly" [#280](https://github.com/rust-lang/compiler-team/issues/280) - "intern predicates, introduce forall/implies" [#285](https://github.com/rust-lang/compiler-team/issues/285) - "Reintegrate chalk into rustc" [#289](https://github.com/rust-lang/compiler-team/issues/289) (NEW) - New proposals (not seconded) - "RFC 2229 implementation plan" [#292](https://github.com/rust-lang/compiler-team/issues/292) - Old proposals (not seconded) - "Integration of the Cranelift backend with rustc" [#270](https://github.com/rust-lang/compiler-team/issues/270) - "Decentralize queries" [#277](https://github.com/rust-lang/compiler-team/issues/277) - "illumos toolchain builds" [#279](https://github.com/rust-lang/compiler-team/issues/279) ## Beta-nominations [T-compiler beta noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Abeta-nominated+label%3AT-compiler) - "Fix hang in lexical_region_resolve" [#72087](https://github.com/rust-lang/rust/pull/72087) :back: / :hand: - "Fix E0284 to not use incorrect wording" [#71960](https://github.com/rust-lang/rust/pull/71960) :back: / :hand: ## Stable-nominations [T-compiler stable noms](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=label%3Astable-nominated+label%3AT-compiler+) No stable nominations this time. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler+) No PR's waiting on team this time. ## Issues of Note ### Short Summary - [1 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) - [0 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) - [42 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) - [22 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [2 P-high and 3 P-medium regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - There is only 1 P-high assigned. - [4 P-medium and 1 P-low regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - There is only 1 P-medium assigned. - [71 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [25 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). There are the same `P-critical` issues and 2 more `P-high` issues in comparison with last week. ### P-critical - "Unsoundness due to variance of trait objects WRT associated type" [#71550](https://github.com/rust-lang/rust/issues/71550) - This issue is assigned to @spastorino and has a PR open. - We've run crater and got a bunch of results. - Niko is investigating possibilities and started a [HackMD with regressions if PR applies](https://hackmd.io/CxycII6iT8iFjbMr0eQcEQ). ### Unassigned P-high regressions - "`forbid` overwritten by later `allow` on the same "scope level"" [#70819](https://github.com/rust-lang/rust/issues/70819) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - "vec macro into_boxed codegen regression" [#71861](https://github.com/rust-lang/rust/issues/71861) - "'rustc' panicked at 'failed to lookup `SourceFile` in new context'" [#70924](https://github.com/rust-lang/rust/issues/70924) `libs-impl` nominations ... - "Regression in usable type complexity: overflow representing the type `...`" [#71359](https://github.com/rust-lang/rust/issues/71359) - "`nth_back()` for `Zip` returns wrong values" [#68536](https://github.com/rust-lang/rust/issues/68536) - "Backtrace is for dynamic library loaded through dlopen using absolute file path for rust >= 1.37.0 on OSX" [#67599](https://github.com/rust-lang/rust/issues/67599) - See [Alex comment](https://github.com/rust-lang/rust/issues/67599#issuecomment-628687241) maybe there's no point in keeping this one nominated. ## WG checkins @**WG-traits** checkin by @**nikomatsakis**: > Checkin text --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 05 21 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-05-21.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-05-21 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - We have a design meeting tomorrow: "codegen unit partitioning" - Major Changes Proposals: - Seconded proposals (in FCP) - "Implement LLVM-compatible source-based code coverage" [#278](https://github.com/rust-lang/compiler-team/issues/278) - "Inline assembly" [#280](https://github.com/rust-lang/compiler-team/issues/280) - "intern predicates, introduce forall/implies" [#285](https://github.com/rust-lang/compiler-team/issues/285) - "Reintegrate chalk into rustc" [#289](https://github.com/rust-lang/compiler-team/issues/289) (NEW) - "RFC 2229 implementation plan" [#292](https://github.com/rust-lang/compiler-team/issues/292) (NEW) - New proposals (not seconded) - "create windows target group" [#293](https://github.com/rust-lang/compiler-team/issues/293) - "Remove Spans from HIR" [#294](https://github.com/rust-lang/compiler-team/issues/294) - Old proposals (not seconded) - "Integration of the Cranelift backend with rustc" [#270](https://github.com/rust-lang/compiler-team/issues/270) - "Decentralize queries" [#277](https://github.com/rust-lang/compiler-team/issues/277) - "illumos toolchain builds" [#279](https://github.com/rust-lang/compiler-team/issues/279) ## Beta-nominations No beta nominations this time for `T-compiler` and `libs-impl`. There's one about `T-rustdoc` ... - "Bump pulldown-cmark" [#71682](https://github.com/rust-lang/rust/pull/71682) ## Stable-nominations No stable nominations this time. ## PR's S-waiting-on-team No PR's waiting on team this time. ## Issues of Note ### Short Summary - [2 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) - [0 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) - [41 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) - [21 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [3 P-high, 3 P-medium, 0 P-low regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - There is only one P-high assigned. - [0 P-high, 4 P-medium, 1 P-low regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - There is only one P-medium assigned. - [72 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [25 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). There is one more `P-critical` issues and one less `P-high` issues in comparison with last week. ### P-critical - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - This issue is assigned to @spastorino and has an PR open. - We've run crater and got a bunch of results. - Niko is investigating possibilities and started a [HackMD with regressions if PR applies](https://hackmd.io/CxycII6iT8iFjbMr0eQcEQ). - "Trait object with non-static lifetime is accepted where static lifetime is expected and required" [#72315](https://github.com/rust-lang/rust/issues/72315) - This issue is assigned to @matthewjasper - This issue may be a variation of the previous one - Needs mcve and we need to find out if it's a dupe of the previous one. ### Unassigned P-high regressions - "`forbid` overwritten by later `allow` on the same "scope level"" [#70819](https://github.com/rust-lang/rust/issues/70819) - "'rustc' panicked at 'failed to lookup `SourceFile` in new context'" [#70924](https://github.com/rust-lang/rust/issues/70924) - This one is also nominated ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - "'rustc' panicked at 'failed to lookup `SourceFile` in new context'" [#70924](https://github.com/rust-lang/rust/issues/70924) - Incremental compilation regression - There are reproduction steps and the [PR where this regressed identified](https://github.com/rust-lang/rust/issues/70924), PR by @eddyb. - "vec macro into_boxed codegen regression" [#71861](https://github.com/rust-lang/rust/issues/71861) - codegen regression - Cleanup Crew is pinged - Unsure how much would we be able to discuss with the given information [libs-impl I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3Alibs-impl) - "Integer overflow on String::drain() with an inclusive range" [#72237](https://github.com/rust-lang/rust/issues/72237) - There are a bunch of methods in stdlib with this same problem. - "Regression in usable type complexity: overflow representing the type `...`" [#71359](https://github.com/rust-lang/rust/issues/71359) - Regression from beta to stable in a [rollup](https://github.com/rust-lang/rust/pull/70943) - "`nth_back()` for `Zip` returns wrong values" [#68536](https://github.com/rust-lang/rust/issues/68536) - "Backtrace is for dynamic library loaded through dlopen using absolute file path for rust >= 1.37.0 on OSX" [#67599](https://github.com/rust-lang/rust/issues/67599) ## WG checkins @**WG-traits** checkin by @**nikomatsakis**: > Checkin text @**WG-async-foundations** checkin by @**nikomatsakis**: > Checkin text @**WG-diagnostics** checkin by @**estebank**: > Checkin text --- ### Minutes Triage Meeting T Compiler Meeting Agenda 2020 05 28 (`content/minutes/triage-meeting/T-compiler Meeting Agenda 2020-05-28.md`) --- tags: weekly, rustc --- # T-compiler Meeting Agenda 2020-05-28 [Tracking Issue](https://github.com/rust-lang/rust/issues/54818) ## Announcements - Tomorrow (Friday 29th) we have a [design meeting: Compiler team 2020-2021 roadmap](https://github.com/rust-lang/compiler-team/issues/287) - Major Changes Proposals: - Seconded proposals (in FCP) - "Reintegrate chalk into rustc" [#289](https://github.com/rust-lang/compiler-team/issues/289) - "RFC 2229 implementation plan" [#292](https://github.com/rust-lang/compiler-team/issues/292) - "create windows working group" [#293](https://github.com/rust-lang/compiler-team/issues/293) - "Remove Spans from HIR" [#294](https://github.com/rust-lang/compiler-team/issues/294) - "move leak-check to during coherence, candidate eval" [#295](https://github.com/rust-lang/compiler-team/issues/295) - "Introduce `ty_error`/`ty_error_with_message`/`ty_error_const` to construct error type or const" [#297](https://github.com/rust-lang/compiler-team/issues/297) (NEW) - New proposals (not seconded) - "Make `CONTRIBUTING.md` into a series of tutorials" [#296](https://github.com/rust-lang/compiler-team/issues/296) - Old proposals (not seconded) - "Integration of the Cranelift backend with rustc" [#270](https://github.com/rust-lang/compiler-team/issues/270) - "Decentralize queries" [#277](https://github.com/rust-lang/compiler-team/issues/277) - "illumos toolchain builds" [#279](https://github.com/rust-lang/compiler-team/issues/279) ## Beta-nominations No beta nominations this time for `T-compiler` and `libs-impl`. ## Stable-nominations No stable nominations this time for `T-compiler` and `libs-impl`. ## PR's S-waiting-on-team [T-compiler S-waiting-on-team](https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Aopen+label%3AS-waiting-on-team+label%3AT-compiler) - "Print environment variables accessed by rustc as special comments into depinfo files" [#71858](https://github.com/rust-lang/rust/pull/71858) - In FCP, disposition to merge. No PR’s waiting on `libs-impl` this time. ## Issues of Note ### Short Summary - [5 P-critical issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+) - [2 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-critical+no%3Aassignee) - [40 P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+) - [17 of those are unassigned](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AT-compiler+label%3AP-high+no%3Aassignee) - [2 P-high, 3 P-medium, 0 P-low regression-from-stable-to-beta](https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta) - Both P-high are assigned. - [3 P-critical, 1 P-high, 3 P-medium, 1 P-low regression-from-stable-to-nightly](https://github.com/rust-lang/rust/labels/regression-from-stable-to-nightly) - There is only 1 P-critical assigned. - [73 regression-from-stable-to-stable](https://github.com/rust-lang/rust/labels/regression-from-stable-to-stable) - [21 of those are not prioritized](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Aregression-from-stable-to-stable+-label%3AP-critical+-label%3AP-high+-label%3AP-medium+-label%3AP-low). There are 3 more `P-critical` issues and 1 less `P-high` issues in comparison with last week. ### P-critical - "Unsoundness due to variance of trait objects WRT associated types" [#71550](https://github.com/rust-lang/rust/issues/71550) - This issue is assigned to @spastorino and has an [PR open](https://github.com/rust-lang/rust/pull/71896). - Crater run from the fix suggested 16 non-spurious regressions. - Niko suspects we should land the PR, at the start of a release cycle. - "Trait object with non-static lifetime is accepted where static lifetime is expected and required" [#72315](https://github.com/rust-lang/rust/issues/72315) - This issue is related to the previous one, and fixed by the same PR. - "LLVM error: "Instruction does not dominate all uses!" on Windows" [#72470](https://github.com/rust-lang/rust/issues/72470) - It is also a regression - supposedly injected by [PR #71840](https://github.com/rust-lang/rust/pull/71840) - (assign to matthew jasper?) - Rejects valid code. - It's windows only. - This seems to indicate incorrect MIR being generated. - "Incorrect non-exhaustive pattern error" [#72476](https://github.com/rust-lang/rust/issues/72476) - It is also a regression. - supposedly injected by [PR #71930](https://github.com/rust-lang/rust/pull/71930) - (assign to Nadrieril?) - Has [an open PR](https://github.com/rust-lang/rust/pull/72506) that likely will fix the issue. - Rejects valid code. - Really quickly detected (2 days). - Seems to be a problem when pattern matching on structs/enums which contain a projection. - "error: expected identifier when building time-macros-impl v0.1.1" [#72545](https://github.com/rust-lang/rust/issues/72545) - It is also a regression. - Detected on day one. - Affects at least time, wasm-bindgen and syn. - It was also reported as https://github.com/rust-lang/rust/issues/72608 ### Unassigned P-high regressions - "ICE in _match.rs:1184:21 when building "gfx-backend-metal" on Nightly" [#72467](https://github.com/rust-lang/rust/issues/72467) - There's [a PR](https://github.com/rust-lang/rust/pull/72506) that may fix this issue. ## Performance logs Triage done by njn. Regressions - [Update to LLVM 10](https://github.com/rust-lang/rust/pull/67759) ([instructions](https://perf.rust-lang.org/compare.html?start=0aa6751c19d3ba80df5b0b02c00bf44e13c97e80&end=82911b3bba76e73afe2881b732fe6b0edb35d5d3&stat=instructions:u)): Lots of grumbling about this. wg-prioritization will consider at their next meeting? - [Intern predicates](https://github.com/rust-lang/rust/pull/72055) ([instructions](https://perf.rust-lang.org/compare.html?start=9310e3bd4f425f84fc27878ebf2bda1f30935a63&end=d9417b385145af1cabd0be8a95c65075d2fc30ff&stat=instructions:u)): @lcnr has promised a follow-up to at least partly fix it, currently in [#72494](https://github.com/rust-lang/rust/pull/72494). Improvements - [Remove ReScope](https://github.com/rust-lang/rust/pull/72362 ([instructions](https://perf.rust-lang.org/compare.html?start=3137f8e2d141d7d7c65040a718a9193f50e1282e&end=52b605c8cb2f730e607de0777a694cd1b9bb3e15&stat=instructions:u)) - [Dumb NRVO](https://github.com/rust-lang/rust/pull/72205) ([instructions](https://perf.rust-lang.org/compare.html?start=963bf528292d8f97104515e32908e30c2467b6a8&end=7f79e98c0356642db62e5113327e436c951e843d&stat=instructions:u)) ## Nominated Issues [T-compiler I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler) - Should we backout LLVM 10? - Update to LLVM 10 [#67759](https://github.com/rust-lang/rust/pull/67759) - It's generating slower code. - "tag/niche terminology cleanup" [#72497](https://github.com/rust-lang/rust/pull/72497) [libs-impl I-nominated](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3Alibs-impl) - "`nth_back()` for `Zip` returns wrong values" [#68536](https://github.com/rust-lang/rust/issues/68536) - "Backtrace is for dynamic library loaded through dlopen using absolute file path for rust >= 1.37.0 on OSX" [#67599](https://github.com/rust-lang/rust/issues/67599) ## WG checkins @**WG-rustc-dev-guide** checkin by @**spastorino**: >Accomplished: > >- [Overview chapter is now merged](https://github.com/rust-lang/rustc-dev-guide/pull/633) > - [You can view it here](https://rustc-dev-guide.rust-lang.org/overview.html) >- Resolved tech debt: > - [Added some notes from estabank about diagnostics](https://github.com/rust-lang/rustc-dev-guide/pull/524) > - [Added more notes from ehuss about diagnostics](https://github.com/rust-lang/rustc-dev-guide/pull/716) > - [Added some guidelines from ehuss on CLI flags](https://github.com/rust-lang/rustc-dev-guide/pull/717) > - [Clean up the trait-solving chapters](https://github.com/rust-lang/rustc-dev-guide/pull/679) > - [Make it possible to link to specific items in the glossary](https://github.com/rust-lang/rustc-dev-guide/pull/662) > - [Finally finished the macro expansion chapter from discussions with petrochenkov (this is a long-standing hole)](https://github.com/rust-lang/rustc-dev-guide/pull/683) > - [Added some (limited) notes about parallel compilation](https://github.com/rust-lang/rustc-dev-guide/pull/695) > - [Added and updated notes on `rustc_interface` (thanks to georgewfraser)](https://rustc-dev-guide.rust-lang.org/rustc-driver.html) > - [Resolved some old TODOs around the type system](https://github.com/rust-lang/rustc-dev-guide/pull/697) > - [Added "Debugging rustc type layouts" (thanks Ralf!)](https://github.com/rust-lang/rustc-dev-guide/pull/720) >- [39 merged PRs](https://github.com/rust-lang/rustc-dev-guide/pulls?page=1&q=is%3Aclosed+closed%3A%3E2020-04-08) >- [15 closed issues (a few were very long-standing)](https://github.com/rust-lang/rustc-dev-guide/issues?q=is%3Aissue+is%3Aclosed+closed%3A%3E2020-04-08+) > >We've also had a few discussions to flesh out the guide vs forge content. > >Next steps: > >- Focus on triaging issues in the repo for a full sprint > - Try to close/consolidate old issues, resolve low-hanging fruit >- Do a second pass about the organization of the guide > - Re-visit part 1, decide what we want to keep vs the forge vs the compiler-team repo > - Want to have a "Getting started" section at the front that has relatively straight-forward list of commands to do common things; move some content there from CONTRIBUTING.md > - Thinking about an instrospection section that contains debugging/profiling/walkthrough/tools/etc. @**WG-llvm** checkin by @**nagisa**: > No updates --- --- METRICS --- - Files Extracted: 120 - Estimated Token Budget: ~127031 tokens - Canonical Reference: https://codewiki.google/github.com/rust-lang/compiler-team