WIP: Initial implementation of or-pattern handling in MIR #63688

dlrobertson · 2019-08-18T16:11:32Z

Building on #64508, #64111, #63693, and #61708, this PR adds:

Initial implementation of or-pattern lowering to MIR.
Basic ui tests for or-patterns

CC #54883

r? @matthewjasper

src/librustc_mir/build/matches/mod.rs

src/librustc_mir/build/matches/test.rs

src/test/ui/or-patterns/basic-switch.rs

src/test/ui/or-patterns/basic-switchint.rs

src/test/ui/or-patterns/mix-with-wild.rs

src/librustc_mir/hair/pattern/mod.rs

dlrobertson · 2019-08-21T04:08:11Z

@Centril thanks for the comments! Updated to take into account your feedback. Let me know if I missed something.

dlrobertson · 2019-08-25T20:19:47Z

ping @matthewjasper any thoughts on how I build the MIR for the or-pattern?

matthewjasper

This seems like a reasonable first step. I think you might be better off using match_candidates for Or tests, since handling complex or patterns (e.g. (1, 1, _) | (_, 2, 2)) would require duplication of most of the remaining match_candidates code.

I've left a couple of comments for other things I noticed when looking through the changes.

matthewjasper · 2019-08-26T07:52:05Z

src/librustc_mir/hair/pattern/mod.rs

 pub struct FieldPattern<'tcx> {
    pub field: Field,
    pub pattern: Pattern<'tcx>,
 }

-#[derive(Clone, Debug)]
+#[derive(Clone, Debug, PartialEq)]


I can't see where these PartialEq impls are used. What is the intended meaning of == here?

matthewjasper · 2019-08-26T07:53:41Z

src/test/ui/or-patterns/basic-switch.rs

+// `SwitchInt` (an `enum`).
+// run-pass
+#![feature(or_patterns)]
+//~^ WARN the feature `or_patterns` is incomplete and may cause the compiler to crash


Can you allow this warning for the tests here?

dlrobertson · 2019-08-26T13:51:13Z

@matthewjasper I couldn't figure out a way to use match_candidates that didn't result in a blow-up of code evaluated as noted in the RFC implementation notes. Given Foo(A | B, C | D) wouldn't we need to expand the or-pattern to the following candidates?

Candidate 1 match pairs:
  .0: A
  .1: C
Candidate 2 match pairs:
  .0: A
  .1: D
Candidate 3 match pairs:
  .0: B
  .1: C
Candidate 4 match pairs:
  .0: B
  .1: D

It may be that I overlooked something, so please let me know if there is another way to generate the correct candidates for an or-pattern, or if I am misunderstanding Candidates.

matthewjasper · 2019-08-26T14:54:16Z

An or pattern would create a new set of candidates for just that pattern.

First Or pattern
Candidate 1 match pairs:
  .0: A
Candidate 2 match pairs:
  .0: B

Second or pattern
Candidate 1 match pairs:
  .1: C
Candidate 2 match pairs:
  .1: D

dlrobertson · 2019-08-26T17:21:59Z

Ah I see... Yeah that could work. I'll try that out.

Centril · 2019-09-06T11:55:40Z

@dlrobertson Now that #64111 landed, you might want to try tests with bindings as well if this PR would support that. See https://github.com/rust-lang/rust/pull/64111/files#diff-03c5a135508e329a1f3eae00e79f9ad4R42 for a relevant test.

dlrobertson · 2019-09-08T01:40:53Z

Awesome! Thanks... I think it should work more or less without much effort once I move to using a Candidate instead of manually manipulating the CFG

dlrobertson · 2019-09-16T13:21:35Z

Working on figuring out where the best place to put the expansion of candidates is (Placing it with match pair simplification would cause exponential blow-up). And we currently don't assume that the list of candidates is grow-able, so I'm also working on correctly handling that.

@dlrobertson

or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR Following up on work in rust-lang#64111, rust-lang#63693, and rust-lang#61708, in this PR: - We change `hair::Arm.patterns: Vec<Pattern<'_>>` into `hir::Arm.pattern: Pattern<'_>`. - `fn hair::Arm::top_pats_hack` is introduced as a temporary crutch in MIR building to avoid more changes. - We change `hir::Arm.pats: HirVec<P<Pat>>` into `hir::Arm.pat: P<Pat>`. - The hacks in `rustc::hir::lowering` are removed since the representation hack is no longer necessary. - In some places, `fn hir::Arm::top_pats_hack` is introduced to leave some things as future work. - Misc changes: HIR pretty printing is adjusted to behave uniformly wrt. top/inner levels, rvalue promotion is adjusted, regionck, and dead_code is also. - Type checking is adjusted to uniformly handle or-patterns at top/inner levels. To make things compile, `p_0 | ... | p_n` is redefined as a "reference pattern" in [`fn is_non_ref_pat`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat) for now. This is done so that reference types are not eagerly stripped from the `expected: Ty<'tcx>`. - Liveness is adjusted wrt. the `unused_variables` and `unused_assignments` lints to handle top/inner levels uniformly and the handling of `fn` parameters, `let` locals, and `match` arms are unified in this respect. This is not tested for now as exhaustiveness checks are reachable and will ICE. - In `check_match`, checking `@` and by-move bindings is adjusted. However, exhaustiveness checking is not adjusted the moment and is handled by @dlrobertson in rust-lang#63688. - AST borrowck (`construct.rs`) is not adjusted as AST borrowck will be removed soon. r? @matthewjasper cc @dlrobertson @varkor @oli-obk

@dlrobertson

or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR Following up on work in #64111, #63693, and #61708, in this PR: - We change `hair::Arm.patterns: Vec<Pattern<'_>>` into `hir::Arm.pattern: Pattern<'_>`. - `fn hair::Arm::top_pats_hack` is introduced as a temporary crutch in MIR building to avoid more changes. - We change `hir::Arm.pats: HirVec<P<Pat>>` into `hir::Arm.pat: P<Pat>`. - The hacks in `rustc::hir::lowering` are removed since the representation hack is no longer necessary. - In some places, `fn hir::Arm::top_pats_hack` is introduced to leave some things as future work. - Misc changes: HIR pretty printing is adjusted to behave uniformly wrt. top/inner levels, rvalue promotion is adjusted, regionck, and dead_code is also. - Type checking is adjusted to uniformly handle or-patterns at top/inner levels. To make things compile, `p_0 | ... | p_n` is redefined as a "reference pattern" in [`fn is_non_ref_pat`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat) for now. This is done so that reference types are not eagerly stripped from the `expected: Ty<'tcx>`. - Liveness is adjusted wrt. the `unused_variables` and `unused_assignments` lints to handle top/inner levels uniformly and the handling of `fn` parameters, `let` locals, and `match` arms are unified in this respect. This is not tested for now as exhaustiveness checks are reachable and will ICE. - In `check_match`, checking `@` and by-move bindings is adjusted. However, exhaustiveness checking is not adjusted the moment and is handled by @dlrobertson in #63688. - AST borrowck (`construct.rs`) is not adjusted as AST borrowck will be removed soon. r? @matthewjasper cc @dlrobertson @varkor @oli-obk

dlrobertson · 2019-09-23T19:52:46Z

Still working on it. I've got single or patterns in a pattern working (Foo(A | B)), but I've got some work to do on (Foo(A | B, C | D)).

Also my current implementation is super hacky... Got a lot of cleanup to do.

@dlrobertson

or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR Following up on work in rust-lang#64111, rust-lang#63693, and rust-lang#61708, in this PR: - We change `hair::Arm.patterns: Vec<Pattern<'_>>` into `hir::Arm.pattern: Pattern<'_>`. - `fn hair::Arm::top_pats_hack` is introduced as a temporary crutch in MIR building to avoid more changes. - We change `hir::Arm.pats: HirVec<P<Pat>>` into `hir::Arm.pat: P<Pat>`. - The hacks in `rustc::hir::lowering` are removed since the representation hack is no longer necessary. - In some places, `fn hir::Arm::top_pats_hack` is introduced to leave some things as future work. - Misc changes: HIR pretty printing is adjusted to behave uniformly wrt. top/inner levels, rvalue promotion is adjusted, regionck, and dead_code is also. - Type checking is adjusted to uniformly handle or-patterns at top/inner levels. To make things compile, `p_0 | ... | p_n` is redefined as a "reference pattern" in [`fn is_non_ref_pat`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat) for now. This is done so that reference types are not eagerly stripped from the `expected: Ty<'tcx>`. - Liveness is adjusted wrt. the `unused_variables` and `unused_assignments` lints to handle top/inner levels uniformly and the handling of `fn` parameters, `let` locals, and `match` arms are unified in this respect. This is not tested for now as exhaustiveness checks are reachable and will ICE. - In `check_match`, checking `@` and by-move bindings is adjusted. However, exhaustiveness checking is not adjusted the moment and is handled by @dlrobertson in rust-lang#63688. - AST borrowck (`construct.rs`) is not adjusted as AST borrowck will be removed soon. r? @matthewjasper cc @dlrobertson @varkor @oli-obk

Centril · 2019-09-27T03:22:01Z

With #64508 merged, it should now be possible to unify the MIR building of or-patterns and link up exhaustiveness checking as well.

dlrobertson · 2019-10-06T00:32:31Z

This PR has sat idle for the last 9 days. And you please address the merge conflicts?

Yeah, working on a complete overhaul of the PR. It's gonna take a bit. The conflicts will be resolved when I push up the changes from the overhaul. While the initial implementation works, a more complete implementation will not directly manipulate the CFG (what I'm working on).

src/librustc_mir/hair/pattern/_match.rs

Nadrieril · 2019-10-18T12:01:55Z

I was invited to work on the exhaustiveness checking part of this PR (and I'm very excited !). Is it possible to test the exhaustiveness part independently ? If not, how can we coordinate ?

Centril · 2019-10-18T13:05:12Z

@Nadrieril I've made a Zulip thread for the work on or-patterns where we can coordinate.

Wrt. testing, I believe we can implement exhaustiveness checking for or-patterns independently of MIR building. We can also add tests for cases where the matches are non-exhaustive as this should never reach MIR building. However, for the exhaustive cases this should result in ICEs because MIR building is reachable and I'm not sure if we can test for those in the current rustbuild infrastructure (although I recall @oli-obk saying something about ways to do it). What we could try is to insert a non-exhaustive match that is unrelated to or-patterns just as a canary to make MIR building unreachable. In any case, some incremental progress would be great. :)

dlrobertson · 2019-10-18T13:37:12Z

@Dylan-DPC posted an update in the Zulip thread.

oli-obk · 2019-10-18T15:00:26Z

However, for the exhaustive cases this should result in ICEs because MIR building is reachable and I'm not sure if we can test for those in the current rustbuild infrastructure (although I recall @oli-obk saying something about ways to do it).

Search for tests using -Ztreat-err-as-bug. There's a comment-flag that you need to add (not the -Ztreat-err-as-bug) in order for the exit code of an ICE to be accepted as making the test "pass".

Handle or-patterns when building MIR by expanding the MatchPair into n Candidates.

Add some basic run-pass ui tests for or-patterns.

dlrobertson · 2019-10-28T02:39:10Z

Updated... It largely consists of hacks and the current code was written in a manner to make debugging easier on me. Things that I know of that have yet to be implemented/fixed:

completeness and unreachability checking (see the range pattern test warning)
<pat0>(q @ <pat1> | q @ <pat2>) currently causes and ICE or compiler error
Code cleanup

src/test/ui/or-patterns/basic-switchint.rs

matthewjasper · 2019-11-02T20:47:23Z

src/librustc_mir/build/matches/mod.rs

+        // FIXME(dlrobertson): This could use some cleaning up.
+        if let PatKind::Or { ref pats } = *match_pair.pattern.kind {
+            let match_pairs = mem::take(&mut candidates.first_mut().unwrap().match_pairs);
+            let mut new_candidates = pats.iter().map(|pat| {


I was expecting these to be an entirely new set of candidates, containing only the match pairs that come from the or pattern. So this function would call match_candidates 3 times: once for the first candidate, once for the remaining candidates and once for the new candidates from the or pattern.

dlrobertson · 2019-12-11T17:42:39Z

awesome sounds good

rust-highfive assigned matthewjasper Aug 18, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 18, 2019

Centril reviewed Aug 18, 2019

View reviewed changes

Centril added the F-or_patterns `#![feature(or_patterns)]` label Aug 18, 2019

Centril reviewed Aug 18, 2019

View reviewed changes

src/librustc_mir/hair/pattern/mod.rs Outdated Show resolved Hide resolved

rust-lang deleted a comment Aug 20, 2019

dlrobertson mentioned this pull request Aug 21, 2019

Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e Foo(Bar(x) | Baz(x))" #54883

Closed

8 tasks

dlrobertson force-pushed the or-patterns-1 branch from 0a13430 to 1991dbd Compare August 21, 2019 04:06

matthewjasper reviewed Aug 26, 2019

View reviewed changes

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 6, 2019

dlrobertson mentioned this pull request Sep 8, 2019

save-analysis: Nest typeck tables when processing functions/methods #64250

Merged

This comment has been minimized.

Sign in to view

Centril mentioned this pull request Sep 16, 2019

or-patterns: Push PatKind/PatternKind::Or at top level to HIR & HAIR #64508

Merged

This comment has been minimized.

Sign in to view

dlrobertson changed the title ~~Initial implementation of or-pattern handling in MIR~~ WIP: Initial implementation of or-pattern handling in MIR Oct 6, 2019

Nadrieril reviewed Oct 6, 2019

View reviewed changes

src/librustc_mir/hair/pattern/_match.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

dlrobertson added 2 commits October 28, 2019 02:13

rustc_mir: match pair with or-pattern handling

619fc1b

Handle or-patterns when building MIR by expanding the MatchPair into n Candidates.

basic run-pass tests for or-patterns

1bf639a

Add some basic run-pass ui tests for or-patterns.

dlrobertson force-pushed the or-patterns-1 branch from 1991dbd to 1bf639a Compare October 28, 2019 02:28

dlrobertson commented Oct 28, 2019

View reviewed changes

src/test/ui/or-patterns/basic-switchint.rs Show resolved Hide resolved

This comment has been minimized.

Sign in to view

matthewjasper reviewed Nov 2, 2019

View reviewed changes

This comment has been minimized.

Sign in to view

JohnCSimon closed this Dec 7, 2019

JohnCSimon added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Dec 7, 2019

Nadrieril mentioned this pull request Dec 29, 2019

Implement MIR lowering for or-patterns #67668

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Initial implementation of or-pattern handling in MIR #63688

WIP: Initial implementation of or-pattern handling in MIR #63688

dlrobertson commented Aug 18, 2019 •

edited by Centril

Loading

dlrobertson commented Aug 21, 2019

dlrobertson commented Aug 25, 2019

matthewjasper left a comment

matthewjasper Aug 26, 2019

matthewjasper Aug 26, 2019

dlrobertson commented Aug 26, 2019

matthewjasper commented Aug 26, 2019

dlrobertson commented Aug 26, 2019

This comment has been minimized.

Centril commented Sep 6, 2019 •

edited

Loading

dlrobertson commented Sep 8, 2019

This comment has been minimized.

dlrobertson commented Sep 16, 2019

This comment has been minimized.

dlrobertson commented Sep 23, 2019 •

edited

Loading

This comment has been minimized.

Centril commented Sep 27, 2019

This comment has been minimized.

dlrobertson commented Oct 6, 2019

This comment has been minimized.

Nadrieril commented Oct 18, 2019

This comment has been minimized.

Centril commented Oct 18, 2019

dlrobertson commented Oct 18, 2019

oli-obk commented Oct 18, 2019

This comment has been minimized.

dlrobertson commented Oct 28, 2019 •

edited

Loading

This comment has been minimized.

matthewjasper Nov 2, 2019

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

dlrobertson commented Dec 11, 2019

WIP: Initial implementation of or-pattern handling in MIR #63688

WIP: Initial implementation of or-pattern handling in MIR #63688

Conversation

dlrobertson commented Aug 18, 2019 • edited by Centril Loading

dlrobertson commented Aug 21, 2019

dlrobertson commented Aug 25, 2019

matthewjasper left a comment

Choose a reason for hiding this comment

matthewjasper Aug 26, 2019

Choose a reason for hiding this comment

matthewjasper Aug 26, 2019

Choose a reason for hiding this comment

dlrobertson commented Aug 26, 2019

matthewjasper commented Aug 26, 2019

dlrobertson commented Aug 26, 2019

This comment has been minimized.

Centril commented Sep 6, 2019 • edited Loading

dlrobertson commented Sep 8, 2019

This comment has been minimized.

dlrobertson commented Sep 16, 2019

This comment has been minimized.

dlrobertson commented Sep 23, 2019 • edited Loading

This comment has been minimized.

Centril commented Sep 27, 2019

This comment has been minimized.

dlrobertson commented Oct 6, 2019

This comment has been minimized.

Nadrieril commented Oct 18, 2019

This comment has been minimized.

Centril commented Oct 18, 2019

dlrobertson commented Oct 18, 2019

oli-obk commented Oct 18, 2019

This comment has been minimized.

dlrobertson commented Oct 28, 2019 • edited Loading

This comment has been minimized.

matthewjasper Nov 2, 2019

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

dlrobertson commented Dec 11, 2019

dlrobertson commented Aug 18, 2019 •

edited by Centril

Loading

Centril commented Sep 6, 2019 •

edited

Loading

dlrobertson commented Sep 23, 2019 •

edited

Loading

dlrobertson commented Oct 28, 2019 •

edited

Loading