T Compiler Meeting Agenda 2026 05 07

T-compiler Meeting Agenda 2026-05-07

Announcements

  • Reminder: if you see a PR/issue that seems like there might be legal implications due to copyright/IP/etc, please let us know (or at least message @davidtwco or @Wesley Wiser so we can pass it along).

Other WG meetings

MCPs/FCPs

Backport nominations

T-compiler beta / T-compiler stable

  • No beta nominations for T-compiler this time.
  • No stable nominations for T-compiler this time.

T-types beta / T-types stable

  • No beta nominations for T-types this time.
  • No stable nominations for T-types this time.

PRs S-waiting-on-t-compiler

T-compiler

Issues of Note

Short Summary

P-critical

T-compiler

  • “1.96 beta regression: “lua does not live long enough”, take 2” rust#155902
    • Will be fixed by #155915 authored by @_dianne
    • backport nomination for T-libs

T-types

  • No P-critical issues for T-types this time.

P-high regressions

P-high beta regressions

  • No P-high beta regressions this time.

Unassigned P-high nightly regressions

  • No unassigned P-high nightly regressions this time.

Need triaging

These beta regressions are not yet completely clear to me:

  • “1.96 beta rustdoc regression: “… is a virtual manifest, but this command requires running against an actual package in this workspace” rust#152992
  • “Regression in calculating value of Result” rust#155985/rust
    • Seem related to the LLVM upgrade, labeled as I-heavy, unsure about the impact. Is this a P-medium-ish codegen regression?
  • “Post-mono cycle ICE with dyn and RPIT” rust#155538
    • Can’t figure out the context, does this lead to an unsoundness? Last comment from @_lcnr

Performance logs

2026-05-05 Triage Log

This week’s result is pretty much neutral. It looks negative in icount numbers, but that’s spurious, wall time remained largely unchanged. Some big performance improvements landed in the new solver, which is not enabled by default, yet.

Triage done by @panstromek. Revision range: ca9a134e..1d72d7e8

Summary:

(instructions:u)meanrangecount
Regressions ?(primary)0.6%[0.2%, 1.2%]106
Regressions ?(secondary)0.7%[0.2%, 2.4%]67
Improvements ?(primary)-0.6%[-1.7%, -0.2%]66
Improvements ?(secondary)-0.6%[-2.8%, -0.0%]60
All ?? (primary)0.1%[-1.7%, 1.2%]172

1 Regression, 2 Improvements, 9 Mixed; 5 of them in rollups 34 artifact comparisons made in total

Regressions

Rollup of 19 pull requests #156023 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)0.3%[0.2%, 0.3%]7
Regressions ?(secondary)0.5%[0.3%, 0.7%]7
Improvements ?(primary)--0
Improvements ?(secondary)--0
All ?? (primary)0.3%[0.2%, 0.3%]7

Tiny regressions in frontend (mainly expand_crate, so likely macro expansion). Primary regressions are limited to very small benchmarks (incr-unchanged), secondary one is just a macro expansion stress test.

I suspect it’s one of the PRs that touches this code - https://github.com/rust-lang/rust/pull/155237, https://github.com/rust-lang/rust/pull/155919 or https://github.com/rust-lang/rust/pull/155980, but all those changes look pretty innocent, so I think it’s probably something like an inlining change caused by moving code around.

I don’t think this is worth digging into more, but the queue is empty, so I kicked off a perf run on https://github.com/rust-lang/rust/pull/155237.

update: Results indicate it was https://github.com/rust-lang/rust/pull/155237 after all. I left a note there.

Improvements

Canonicalize free regions from inputs as placeholders in root univ #155487 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)--0
Improvements ?(primary)--0
Improvements ?(secondary)-1.2%[-2.9%, -0.8%]6
All ?? (primary)--0

Rollup of 9 pull requests #156041 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)--0
Improvements ?(primary)-0.9%[-0.9%, -0.9%]1
Improvements ?(secondary)--0
All ?? (primary)-0.9%[-0.9%, -0.9%]1

Mixed

Remove WithCachedTypeInfo::stable_hash. #155329 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)0.7%[0.3%, 1.5%]113
Regressions ?(secondary)0.7%[0.1%, 2.4%]70
Improvements ?(primary)-0.4%[-0.7%, -0.2%]32
Improvements ?(secondary)-0.3%[-0.7%, -0.0%]36
All ?? (primary)0.5%[-0.7%, 1.5%]145

icount regressions in incr-* cases, as expected in the pre-merge run. Justified by the comment above: https://github.com/rust-lang/rust/pull/155329#issuecomment-4251316568.

We now have more context in surrounding post-merge results, and it looks like this analysis holds up. If I click through wall time results (mostly non-relevant ones), the results look mostly indistinguishable from regular wall-time noise, and they still oscillate around the same level.

Rollup of 6 pull requests #155953 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.0%[0.0%, 0.1%]4
Improvements ?(primary)--0
Improvements ?(secondary)-0.2%[-0.6%, -0.0%]5
All ?? (primary)--0

include-blob regressions look like noise.

Remove attribute parsing Stage #155775 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.0%[0.0%, 0.0%]3
Improvements ?(primary)--0
Improvements ?(secondary)-0.3%[-0.5%, -0.1%]10
All ?? (primary)--0

Triaged by @JonathanBrouwer: “Net positive, regressions are probably noise and very small regardless”

Rollup of 21 pull requests #155979 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.4%[0.3%, 0.5%]12
Improvements ?(primary)-0.6%[-1.7%, -0.1%]33
Improvements ?(secondary)-0.0%[-0.0%, -0.0%]1
All ?? (primary)-0.6%[-1.7%, -0.1%]33

Based on @JonathanBrouwer’s investigations, improvements come mostly from https://github.com/rust-lang/rust/pull/155794, regressions coming mostly from https://github.com/rust-lang/rust/pull/154149, where it was justified because we now do more work to check for ambiguity in imports.

-Znext-solver Eager normalization outside of solver #155767 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)0.2%[0.2%, 0.3%]2
Regressions ?(secondary)4.6%[0.1%, 11.4%]8
Improvements ?(primary)-0.4%[-0.5%, -0.3%]7
Improvements ?(secondary)-1.6%[-6.4%, -0.0%]18
All ?? (primary)-0.2%[-0.5%, 0.3%]9

Marking as triaged based on the comment from @lcnr: non-next solver is mostly noise, the typenum regression is acceptable.

Note that the new solver is not enabled by default. Diesel regression looks maybe real to me, but it’s very tiny, so either way it seems like an acceptable trade-off for a step forward in this work.

Rollup of 4 pull requests #156111 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)0.7%[0.1%, 1.3%]2
Regressions ?(secondary)--0
Improvements ?(primary)-0.7%[-1.3%, -0.3%]10
Improvements ?(secondary)-0.2%[-0.2%, -0.2%]2
All ?? (primary)-0.5%[-1.3%, 1.3%]12

Improvements outweigh regressions. bitmaps regression is very small, maybe noise. Rustdoc regression is probably https://github.com/rust-lang/rust/pull/156073 (only rustdoc-related change), but nothing here seems big enough to revert or investigate more deeply.

Runtime benchmark failure seems spurious, following run built properly.

Move tests array slice vec #156044 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.1%[0.0%, 0.1%]5
Improvements ?(primary)--0
Improvements ?(secondary)-0.2%[-0.6%, -0.0%]4
All ?? (primary)--0

These results are noise, this PR doesn’t modify the compiler.

std: implement clear via truncate #154095 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.2%[0.0%, 0.6%]4
Improvements ?(primary)--0
Improvements ?(secondary)-0.1%[-0.1%, -0.0%]5
All ?? (primary)--0

These results are noise, this PR only adds comment.

Short-circuit calculate_fallback_to_f32 when no float vars #156139 (Comparison Link)

(instructions:u)meanrangecount
Regressions ?(primary)--0
Regressions ?(secondary)0.1%[0.0%, 0.1%]4
Improvements ?(primary)--0
Improvements ?(secondary)-21.0%[-87.6%, -0.0%]18
All ?? (primary)--0

include-blob regressions are noise.

Nominated Issues

T-compiler

  • No I-compiler-nominated issues this time.

RFC

  • No I-compiler-nominated RFCs this time.

Oldest PRs waiting for review

T-compiler

  • “Make bitset would_modify_words more vectorizer-friendly” rust#153640 (last review activity: about 58 days ago)
    • cc: @Mads Marquart (as per comment, unsure if this was a dice roll assignment)
  • “rustdoc: Add [arg@name] intra-doc syntax for referencing function arguments” rust#153734 (last review activity: about 56 days ago)
    • mostly T-rustdoc, some small bits for T-compiler?
  • “Add a suite of ChunkedBitSet union/subtract/intersect test scenarios” rust#153759 (last review activity: about 56 days ago)
    • I think this review can be “stolen” by anyone
  • “hir_typeck: suggest removing redundant .iter() and iter_mut ()calls” rust#153700 (last review activity: about 55 days ago)
    • PR author is looking for feedback from @Esteban Küber

Next meetings’ agenda draft: hackmd link