Skip to content

or-patterns: Uniformly use PatKind::Or in AST & Fix/Cleanup resolve - #64111

Merged
bors merged 27 commits into
rust-lang:masterfrom
Centril:ast-only-patkind-or
Sep 6, 2019
Merged

or-patterns: Uniformly use PatKind::Or in AST & Fix/Cleanup resolve#64111
bors merged 27 commits into
rust-lang:masterfrom
Centril:ast-only-patkind-or

Conversation

@Centril

Copy link
Copy Markdown
Contributor

Following up on work in #63693 and #61708, in this PR we:

  • Uniformly use PatKind::Or(...) in AST:

    • Change ast::Arm.pats: Vec<P<Pat>> => ast::Arm.pat: P<Pat>

    • Change ast::ExprKind::Let.0: Vec<P<Pat>> => ast::ExprKind::Let.0: P<Pat>

  • Adjust librustc_resolve/late.rs to correctly handle or-patterns at any level of nesting as a result.

    In particular, the already-bound check which rejects e.g. let (a, a); now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:

    enumE<T>{A(T,T),B(T)}useE::*;fnfoo(){matchA(0,1){B(mut a) | A(mut a,mut a) => {}}}

    The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.

  • Clean up librustc_resolve/late.rs by, among other things, using a new with_rib function to better ensure stack dicipline.

  • Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in rustc::hir::lowering (clearly marked in the diff).

cc #54883
cc @dlrobertson@matthewjasper
r? @petrochenkov

@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 3, 2019
@CentrilCentril added the F-or_patterns `#![feature(or_patterns)]` label Sep 3, 2019
@rust-highfive

This comment has been minimized.

Comment threadsrc/librustc/hir/lowering/expr.rs Outdated
Comment threadsrc/libsyntax/ast.rs Outdated
Comment threadsrc/librustc_resolve/late.rs Outdated
Comment threadsrc/librustc_resolve/late.rs Outdated
Comment threadsrc/librustc_resolve/late.rs Outdated
Comment threadsrc/librustc_resolve/late.rs Outdated
Comment threadsrc/libsyntax/ast.rs Outdated
Comment threadsrc/libsyntax/visit.rs Outdated
@petrochenkovpetrochenkov 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 3, 2019
@CentrilCentril added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 4, 2019
@Centril

Copy link
Copy Markdown
ContributorAuthor

Addressed the comments, hopefully. :)

Comment threadsrc/librustc_resolve/late.rs Outdated
@petrochenkov

Copy link
Copy Markdown
Contributor

r=me with the remaining comment addressed

@petrochenkovpetrochenkov 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 4, 2019
@Centril

Copy link
Copy Markdown
ContributorAuthor

@bors r=petrochenkov

@bors

bors commented Sep 4, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit 359c3c0865c8a929925972675eb58200cec07133 has been approved by petrochenkov

@borsbors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 4, 2019
@rust-highfive

This comment has been minimized.

@Centril

Copy link
Copy Markdown
ContributorAuthor

Tested locally with ./x.py test src/liballoc --stage 1 before and after rebase. Cannot reproduce the failure. Let's see if rebase changes anything in CI.

Centril added a commit to Centril/rust that referenced this pull request Sep 5, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 5, 2019
@Centril

Copy link
Copy Markdown
ContributorAuthor

Rebased & fixed the fallout from #64128 in 16ba502.

@bors r=petrochenkov

@bors

bors commented Sep 5, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit 16ba502 has been approved by petrochenkov

Centril added a commit to Centril/rust that referenced this pull request Sep 5, 2019
…ochenkov
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in rust-lang#63693 and rust-lang#61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc rust-lang#54883
cc @dlrobertson@matthewjasper
r? @petrochenkov
@CentrilCentril mentioned this pull request Sep 5, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 5, 2019
…ochenkov
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in rust-lang#63693 and rust-lang#61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc rust-lang#54883
cc @dlrobertson@matthewjasper
r? @petrochenkov
@CentrilCentril mentioned this pull request Sep 5, 2019
bors added a commit that referenced this pull request Sep 5, 2019
Rollup of 5 pull requests
Successful merges:
- #63676 (Use wasi crate for Core API)
- #64094 (Improve searching in rustdoc and add tests)
- #64111 (or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve)
- #64156 (Assume non-git LLVM is fresh if the stamp file exists)
- #64175 (Fix invalid span generation when it should be div)
Failed merges:
- #63806 (Upgrade rand to 0.7)
r? @ghost
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 6, 2019
…ochenkov
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in rust-lang#63693 and rust-lang#61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc rust-lang#54883
cc @dlrobertson@matthewjasper
r? @petrochenkov
Centril added a commit to Centril/rust that referenced this pull request Sep 6, 2019
…ochenkov
or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve
Following up on work in rust-lang#63693 and rust-lang#61708, in this PR we:
- Uniformly use `PatKind::Or(...)` in AST:
- Change `ast::Arm.pats: Vec<P<Pat>>` => `ast::Arm.pat: P<Pat>`
- Change `ast::ExprKind::Let.0: Vec<P<Pat>>` => `ast::ExprKind::Let.0: P<Pat>`
- Adjust `librustc_resolve/late.rs` to correctly handle or-patterns at any level of nesting as a result.
In particular, the already-bound check which rejects e.g. `let (a, a);` now accounts for or-patterns. The consistency checking (ensures no missing bindings and binding mode consistency) also now accounts for or-patterns. In the process, a bug was found in the current compiler which allowed:
```rust
enum E<T> { A(T, T), B(T) }
use E::*;
fn foo() {
match A(0, 1) {
B(mut a) | A(mut a, mut a) => {}
}
}
```
The new algorithms took a few iterations to get right. I tried several clever schemes but ultimately a version based on a stack of hashsets and recording product/sum contexts was chosen since it is more clearly correct.
- Clean up `librustc_resolve/late.rs` by, among other things, using a new `with_rib` function to better ensure stack dicipline.
- Do not push the change in AST to HIR for now to avoid doing too much in this PR. To cope with this, we introduce a temporary hack in `rustc::hir::lowering` (clearly marked in the diff).
cc rust-lang#54883
cc @dlrobertson@matthewjasper
r? @petrochenkov
@CentrilCentril mentioned this pull request Sep 6, 2019
bors added a commit that referenced this pull request Sep 6, 2019
Rollup of 10 pull requests
Successful merges:
- #63676 (Use wasi crate for Core API)
- #64094 (Improve searching in rustdoc and add tests)
- #64111 (or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve)
- #64156 (Assume non-git LLVM is fresh if the stamp file exists)
- #64161 (Point at variant on pattern field count mismatch)
- #64174 (Add missing code examples on Iterator trait)
- #64175 (Fix invalid span generation when it should be div)
- #64186 (std: Improve downstream codegen in `Command::env`)
- #64190 (fill metadata in rustc_lexer's Cargo.toml)
- #64198 (Add Fuchsia to actually_monotonic)
Failed merges:
r? @ghost
@bors
bors merged commit 16ba502 into rust-lang:masterSep 6, 2019
@Centril
Centril deleted the ast-only-patkind-or branch September 6, 2019 11:41
mati865 added a commit to mati865/rust-clippy that referenced this pull request Sep 6, 2019
bors added a commit to rust-lang/rust-clippy that referenced this pull request Sep 6, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 22, 2019
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
bors added a commit that referenced this pull request Sep 23, 2019
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
Centril added a commit to Centril/rust that referenced this pull request Sep 25, 2019
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 added a commit to Centril/rust that referenced this pull request Nov 22, 2019
…etrochenkov
resolve: more declarative `fresh_binding`
Following up on rust-lang#64111, this PR redefines `fresh_binding` wrt. `already_bound_and` and `already_bound_or` in a more declarative and simplified fashion.
cc rust-lang#54883
r? @petrochenkov
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

F-or_patterns`#![feature(or_patterns)]`S-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@Centril@rust-highfive@petrochenkov@bors@dlrobertson