Suggest using a qualified path in patterns with inconsistent bindings #63406
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @estebank I made a bit of a logical clean-up in the binding consistency check and seeing this is likely a moderately warm path, could we please have a perf run for this? I'm not sure how to trigger it. I guess special privileges are needed. 🙂 |
|
@bors try EDIT: ... or not? |
|
⌛ Trying commit 7e0d1db with merge efa15a7c07988ce7040c82922eb6bf2f3fbf020b... |
bors
added a commit
that referenced
this pull request
Aug 9, 2019
…qualified-path, r=<try>
Suggest using a qualified path in patterns with inconsistent bindings
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Fixes #50831.
Centril
reviewed
Aug 9, 2019
jakubadamw
commented
Aug 9, 2019
|
☀️ Try build successful - checks-azure |
|
@rust-timer build 8261083 |
|
Insufficient permissions to issue commands to rust-timer. |
|
@rust-timer build 8261083 |
|
Success: Queued 8261083 with parent d8f8be4, comparison URL. |
|
Finished benchmarking try commit 8261083, comparison URL. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@Centril, thank you for the review. I addressed all your comments. |
|
Blocked on #63400. |
petrochenkov
added
S-blocked
|
☔ The latest upstream changes (presumably #63437) made this pull request unmergeable. Please resolve the merge conflicts. |
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Co-Authored-By: Mazdak Farrokhzad <[email protected]>
|
@rustbot modify labels: S-waiting-on-review |
rustbot
added
the
S-waiting-on-review
|
@rustbot modify labels: -S-blocked |
rustbot
removed
the
S-blocked
|
Thanks! |
|
📌 Commit 30db4eb has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Aug 12, 2019
…es-suggest-qualified-path, r=petrochenkov
Suggest using a qualified path in patterns with inconsistent bindings
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Fixes rust-lang#50831.
bors
added a commit
that referenced
this pull request
Aug 12, 2019
Rollup of 10 pull requests Successful merges: - #62108 (Use sharded maps for queries) - #63297 (Improve pointer offset method docs) - #63306 (Adapt AddRetag for shallow retagging) - #63406 (Suggest using a qualified path in patterns with inconsistent bindings) - #63431 (Revert "Simplify MIR generation for logical ops") - #63449 (resolve: Remove remaining special cases from built-in macros) - #63461 (docs: add stdlib env::var(_os) panic) - #63473 (Regression test for #56870) - #63474 (Add tests for issue #53598 and #57700) - #63480 (Fixes #63477) Failed merges: r? @ghost
Centril
added a commit
to Centril/rust
that referenced
this pull request
Aug 12, 2019
…es-suggest-qualified-path, r=petrochenkov
Suggest using a qualified path in patterns with inconsistent bindings
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Fixes rust-lang#50831.
bors
added a commit
that referenced
this pull request
Aug 12, 2019
Rollup of 9 pull requests Successful merges: - #62108 (Use sharded maps for queries) - #63297 (Improve pointer offset method docs) - #63406 (Suggest using a qualified path in patterns with inconsistent bindings) - #63431 (Revert "Simplify MIR generation for logical ops") - #63449 (resolve: Remove remaining special cases from built-in macros) - #63461 (docs: add stdlib env::var(_os) panic) - #63473 (Regression test for #56870) - #63474 (Add tests for issue #53598 and #57700) - #63480 (Fixes #63477) Failed merges: r? @ghost
jakubadamw
deleted the
resolve-inconsistent-names-suggest-qualified-path
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A program like the following one:
is rejected by the compiler due to
Evariant paths not being in scope.In this case
A,Bare resolved as pattern bindings and consequentlythe pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the
non-camel-case-typeslint.Fixes #50831.