Closure capture cleanup & refactor #89861
Conversation
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 691f14023ffcb4e6591655228cdc358b00f282b9 with merge 141f36eb94d72f67dfd9c393c50026f544b48579... |
|
@rust-timer build 141f36eb94d72f67dfd9c393c50026f544b48579 |
|
Queued 141f36eb94d72f67dfd9c393c50026f544b48579 with parent eeb16a2, future comparison URL. |
|
Finished benchmarking commit (141f36eb94d72f67dfd9c393c50026f544b48579): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
rustbot
removed
the
S-waiting-on-perf
apiraino
added
the
T-compiler
|
Rebased to address conflict with #89933 since both introduces some use of let_else. Weird that bors didn't drop a message this time. |
This comment has been minimized.
This comment has been minimized.
JohnCSimon
added
S-waiting-on-review
JohnCSimon
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #91945) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #92099) made this pull request unmergeable. Please resolve the merge conflicts. |
This span is unused and is superseded by capture_kind_expr_id in CaptureInfo
Region info is completely unnecessary for upvar capture kind computation and is only needed to create the final upvar tuple ty. Doing so makes creation of UpvarCapture very cheap and expose further cleanup opportunity.
`adjust_upvar_deref` and friends are implemented so that they reuse existing region so new region vars don't have to be generated. Since now we don't have to generate region vars in `InferBorrowKind`, creating a new capture info would be cheap and we can just use `determine_capture_info`. syn is updated so that let_else syntax can be used in fn with `#[instrument]` attribute. `restrict_repr_packed_field_ref_capture` is changed to take place by value since cloning is needed anyway.
Min capture computation can already handle the same place appearing twice, and previous commits made CaptureInfo construction very cheap, so just delegate all work to min capture and let InferBorrowKind and process_collected_capture_information handle everything linearly.
|
@bors r+ |
|
📌 Commit c84cea9 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (22e491a): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Closure capture cleanup & refactor Follow up of rust-lang#89648 Each commit is self-contained and the rationale/changes are documented in the commit message, so it's advisable to review commit by commit. The code is significantly cleaner (at least IMO), but that could have some perf implication, so I'd suggest a perf run. r? `@wesleywiser` cc `@arora-aman`
Follow up of #89648
Each commit is self-contained and the rationale/changes are documented in the commit message, so it's advisable to review commit by commit.
The code is significantly cleaner (at least IMO), but that could have some perf implication, so I'd suggest a perf run.
r? @wesleywiser
cc @arora-aman