# Announcements for opening of meeting

* Triage meeting yesterday was cancelled.
* pnkfelix unilaterally approved beta backports for [PR #72087](https://github.com/rust-lang/rust/pull/72087) and [PR #71960](https://github.com/rust-lang/rust/pull/71960).

# Meeting Take-aways and Action Items

## hard to find correct usage patterns; communal knowledge is not shared well

* collectively: try to post issues to rustc-dev-guide when you see questions on transient channels like Zulip.
* gather more data: survey new compiler contributors, and/or people who came and bounced. * And probably also the current contributors; but just make sure to ask data about people's experience/contribution level (either in time on project or number of PR's, *something*)

## lack of focus: triage meeting goes into weeds; our chat is forked; our team is too broad

* [Areas of the compiler Meeting #288](https://github.com/rust-lang/compiler-team/issues/288)

# Summary of Survey Results for State of T-compiler

## High Level

1. long standing problems going unaddressed (or hard to track progress thereof; lack of status updates)
2. worker drain and lack of bandwidth.
3. lack of focus: triage meeting goes into weeds; our chat is forked; our team is too broad
4. change-to-test cycle is too long (more broadly, everything is too high latency)
5. hard to find correct usage patterns; communal knowledge is not shared well

## Notes from survey results

(These are largely just transcribed snippets of text from the answers people gave.)

* Making it clear (or easier to identify) when an issue is blocked on a well-known pre-existing problem, e.g. lazy-normalization
* Didn't regressions once get addressed more quickly based on mtg discussion?
* Contributor and paid-employee drain is worrisome
* Prioritization and general to-do list is too broad and unfocused
* Lack of leadership bandwidth
* Lack of mentoring bandwidth
* Lack of review bandwidth (both high review latency and low number of (active?) reviewers)
* Always the same ppl reviewing similar PRs feels like we may be doing lots of stuff that the larger team may disagree with without us knowing they would.

* Lack of regular retrospectives
* Need to dedicate more to time large, long-standing problems (lazy-normalization, specialization) and less to purely syntactical or niche extensions. (Difficult because of "bikeshed" phenomenon; every can have an opinon re: trivia)
* Need more focus on consensus builds for early stage MCPs (and to try to avoid argumentative/combatative tone).
* Meeting time may be difficult
* Discord/Zulip split means community split
* Lots of projects but many are moving very slowly. Creates impression that nothing is happening.
* Popular features like CTFE or compilation time improvements do not really provide status updates.
* Hard to pick next project for cleaning up or fixing things in my area of expertise.
* Not sure we have workforce to accomplish all things that lang team designs. Recent acquistion of T-libs impl may add to this problem.
* T-compiler is too all-encompassing.
* "the tree relationship between it and the various workgroups is either too broad or is an entirely wrong abstraction."
* Debugging rustc is hard/doesn't work, e.g. under `rust-gdb`
* Risk of burnout.
* `rustc`'s change-to-test cycle is too long
* impedes contributing small patches

* Hard to discover usable x.py workflows.
* E.g. building docs and running `libstd` or compiler unit tests without having to build `rustc` is valuable but hard to figure out (and sometimes breaks).
* "ideal" workflows not documented (or perhaps unimplemented).
* "For example, building docs and running libstd or compiler unit tests without having to build a compiler is hugely valuable, but not very easy to figure out (and sometimes it breaks)."

* Tools for introspection (self-profiling, debugging, internal data reps) is 90% there, but needs more work to enable decent workflows.

* Rebasing changes over large refactors is annoying

* T-compiler meeting goes into weeds, or lost purpose.
* PR queue issues:
* slow (low throughput)
* "cannot" do full run of tests on all platforms
* Can one hack that via a mod to the CI file?[name=pnkfelix]

* May need more developer-level docs (doc comments, module comments).
* "I often write lot of boilerplate before noticing function that does the work for me."
* LLVM is a black-box; docs hidden or very sparse
* Hard to find invariants/correct usage patterns (e.g. for `ty::Error` or `ty::Binder`). Communal knowledge is hard to pick up

* Generally unclear ownership of modules/components
* Who owns incr-comp?
* Who is rustc_interface for?
* Lots of const-eval problems lately (presumably due to active efforts there); does it need a stronger test suite?
* Polonius is out-of-tree, which helps with iteration times and ease of contribution, but has drawbacks: no immediate access to various crates and data structures for control-flow graph and dataflow.
* "I find whole query system hard to understand; heavy use of macros is part of problem"
* Too much churn around our codebase
* Lack well-implemented basic prereq's for e.g. alias analysis

## Follow up Notes

* Followup on "From the outside, it's difficult to tell if projects are being worked on and what the roadmap is."
1. we do have "internal" updates but a lot of that happens in various GitHub issues, PRs, things that like which unless you're very active in the project, you don't see and
2. it's hard to find longer-term planning information.