mir_build: Avoid some useless work when visiting "primary" bindings by Zalathar · Pull Request #137465

mir_build: Avoid some useless work when visiting "primary" bindings by Zalathar · Pull Request #137465 · rust-lang/rust

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Feb 23, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 23, 2025

mir_build: Avoid some useless work when visiting "primary" bindings

While looking over `visit_primary_bindings`, I noticed that it does a bunch of extra work to build up a collection of “user-type projections”, even though 2/3 of its call sites don't even use them. Those callers can get the same result via `thir::Pat::walk_always`.

(And it turns out that doing so also avoids creating some redundant user-type entries in MIR for some binding constructs.)

I also noticed that even when the user-type projections *are* used, the process of building them ends up eagerly cloning some nested vectors at every recursion step, even in cases where they won't be used because the current subpattern has no bindings. To avoid this, the visit method now assembles a linked list on the stack containing the information that *would* be needed to create projections, and only creates the concrete projections as needed when a primary binding is encountered.

Some relevant prior PRs:
- rust-lang#55274
- rust-lang@0bfe184 in rust-lang#55937

This avoids the need to unwrap an option after ensuring that it is some.

The existing method does some non-obvious extra work to collect user types and
build user-type projections, which is specifically needed by `declare_bindings`
and not by the other two callers.

bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Mar 17, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 17, 2025

…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#133870 (Stabilize `asm_goto` feature gate)
 - rust-lang#137449 (Denote `ControlFlow` as `#[must_use]`)
 - rust-lang#137465 (mir_build: Avoid some useless work when visiting "primary" bindings)
 - rust-lang#138349 (Emit function declarations for functions with `#[linkage="extern_weak"]`)
 - rust-lang#138412 (Install licenses into `share/doc/rust/licenses`)
 - rust-lang#138577 (rustdoc-json: Don't also include `#[deprecated]` in `Item::attrs`)
 - rust-lang#138588 (Avoid double lowering of idents)

Failed merges:

 - rust-lang#138321 ([bootstrap] Distribute split debuginfo if present)

r? `@ghost`
`@rustbot` modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Mar 17, 2025

Rollup merge of rust-lang#137465 - Zalathar:visit-primary, r=oli-obk

mir_build: Avoid some useless work when visiting "primary" bindings

While looking over `visit_primary_bindings`, I noticed that it does a bunch of extra work to build up a collection of “user-type projections”, even though 2/3 of its call sites don't even use them. Those callers can get the same result via `thir::Pat::walk_always`.

(And it turns out that doing so also avoids creating some redundant user-type entries in MIR for some binding constructs.)

I also noticed that even when the user-type projections *are* used, the process of building them ends up eagerly cloning some nested vectors at every recursion step, even in cases where they won't be used because the current subpattern has no bindings. To avoid this, the visit method now assembles a linked list on the stack containing the information that *would* be needed to create projections, and only creates the concrete projections as needed when a primary binding is encountered.

Some relevant prior PRs:
- rust-lang#55274
- rust-lang@0bfe184 in rust-lang#55937

---

There should be no user-visible change in compiler output.