lower pattern bindings in the order they're written and base drop order on primary bindings' order #143764
Conversation
This avoids scheduling drops and immediately unscheduling them. Drops for guard bindings/temporaries are still scheduled and unscheduled as before.
rustbot
added
S-waiting-on-review
|
Some changes occurred in match lowering cc @Nadrieril |
|
to kick the crater run off @bors2 try |
lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix #142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from #121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with #143376 and probably also #143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
The regressions look unrelated as far as I can tell: 3 crashes in lld and two errors building non-rust dependencies (jq and fltk). The "fixed" crates also look unrelated: previously they'd encountered a file permissions error in a build script, a failure to build a non-rust dependency (jq), and a failure to resolve a dependency (arcstr). I think that means none of the tested crates encountered the change in drop-checking. Hopefully nothing relies on the current drop order for runtime correctness (I'd be surprised/impressed if so!) |
To fix #142163, this PR does two things:
@as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in this test from match lowering: Lower bindings in a predictable order #121716.My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building
FlatPats, I've instead added just enough information to recover the original structure of the pattern's bindings from aMatchTreeSubBranch's path through theCandidatetree. Some alternatives:MatchTreeSubBranches.test_remaining_match_pairs_after_or; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here.This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference.
This will conflict with #143376 and probably also #143028, so they shouldn't be merged at the same time.
r? @matthewjasper or @Nadrieril