mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4ad6248825
rust/src/test/ui/resolve/resolve-inconsistent-names.stderr

102 lines
3.6 KiB
Plaintext
Raw Normal View History

Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
error[E0408]: variable `a` is not bound in all patterns
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 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.
2019-08-09 04:43:26 -05:00
--> $DIR/resolve-inconsistent-names.rs:13:12
Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | a | b => {}
Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
| - ^ pattern doesn't bind `a`
| |
| variable not in all patterns
error[E0408]: variable `b` is not bound in all patterns
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 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.
2019-08-09 04:43:26 -05:00
--> $DIR/resolve-inconsistent-names.rs:13:8
Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | a | b => {}
Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
| ^ - variable not in all patterns
| |
| pattern doesn't bind `b`
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 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.
2019-08-09 04:43:26 -05:00
error[E0408]: variable `A` is not bound in all patterns
--> $DIR/resolve-inconsistent-names.rs:19:18
|
LL | (A, B) | (ref B, c) | (c, A) => ()
| - ^^^^^^^^^^ - variable not in all patterns
| | |
| | pattern doesn't bind `A`
| variable not in all patterns
|
Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-09 15:21:45 -05:00
help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::A`
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 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.
2019-08-09 04:43:26 -05:00
--> $DIR/resolve-inconsistent-names.rs:19:10
|
LL | (A, B) | (ref B, c) | (c, A) => ()
| ^
error[E0408]: variable `B` is not bound in all patterns
--> $DIR/resolve-inconsistent-names.rs:19:31
|
LL | (A, B) | (ref B, c) | (c, A) => ()
| - - ^^^^^^ pattern doesn't bind `B`
| | |
| | variable not in all patterns
| variable not in all patterns
error[E0408]: variable `c` is not bound in all patterns
--> $DIR/resolve-inconsistent-names.rs:19:9
|
LL | (A, B) | (ref B, c) | (c, A) => ()
| ^^^^^^ - - variable not in all patterns
| | |
| | variable not in all patterns
| pattern doesn't bind `c`
error[E0409]: variable `B` is bound in inconsistent ways within the same match arm
--> $DIR/resolve-inconsistent-names.rs:19:23
|
LL | (A, B) | (ref B, c) | (c, A) => ()
| - ^ bound in different ways
| |
| first binding
error[E0408]: variable `CONST1` is not bound in all patterns
--> $DIR/resolve-inconsistent-names.rs:30:23
|
LL | (CONST1, _) | (_, Const2) => ()
| ------ ^^^^^^^^^^^ pattern doesn't bind `CONST1`
| |
| variable not in all patterns
|
Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-09 15:21:45 -05:00
help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::CONST1`
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 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.
2019-08-09 04:43:26 -05:00
--> $DIR/resolve-inconsistent-names.rs:30:10
|
LL | (CONST1, _) | (_, Const2) => ()
| ^^^^^^
error[E0408]: variable `Const2` is not bound in all patterns
--> $DIR/resolve-inconsistent-names.rs:30:9
|
LL | (CONST1, _) | (_, Const2) => ()
| ^^^^^^^^^^^ ------ variable not in all patterns
| |
| pattern doesn't bind `Const2`
|
Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-09 15:21:45 -05:00
help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `?::Const2`
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 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.
2019-08-09 04:43:26 -05:00
--> $DIR/resolve-inconsistent-names.rs:30:27
|
LL | (CONST1, _) | (_, Const2) => ()
| ^^^^^^
error[E0308]: mismatched types
--> $DIR/resolve-inconsistent-names.rs:19:19
|
refactor and fix this-expression-has-type note
2019-12-30 02:08:18 -06:00
LL | match x {
| - this expression has type `(E, E)`
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 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.
2019-08-09 04:43:26 -05:00
LL | (A, B) | (ref B, c) | (c, A) => ()
improve or-pattern type consistency diagnostics
2020-02-24 22:30:43 -06:00
| - ^^^^^ expected enum `E`, found `&E`
| |
| first introduced with type `E` here
|
= note: in the same arm, a binding must have the same type in all alternatives
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 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.
2019-08-09 04:43:26 -05:00
error: aborting due to 9 previous errors
Move compile-fail tests with NOTE/HELP annotations to UI
2017-12-10 13:47:55 -06:00
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 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.
2019-08-09 04:43:26 -05:00
Some errors have detailed explanations: E0308, E0408, E0409.
For more information about an error, try `rustc --explain E0308`.
Reference in New Issue Copy Permalink