Commit Graph

9 Commits

Author SHA1 Message Date
Mazdak Farrokhzad
1d33717583 improve or-pattern type consistency diagnostics 2020-02-25 05:30:43 +01:00
Mazdak Farrokhzad
d7e2f3aee5 refactor and fix this-expression-has-type note 2019-12-30 14:05:17 +01:00
Esteban Küber
6f8f70624b Surround types with backticks in type errors 2019-11-18 11:03:04 -08:00
Esteban Küber
94c6425464 Remove E0308 note when primary label has all info 2019-11-18 11:03:03 -08:00
Jakub Adam Wieczorek
30db4ebdc2 Apply suggestions from code review
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-08-10 21:09:53 +00:00
Jakub Adam Wieczorek
53a6304c2a 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-10 21:09:53 +00:00
Vadim Petrochenkov
fa72a81bea Update tests 2019-03-11 23:10:26 +03:00
Mark Rousskov
2a663555dd Remove licenses 2018-12-25 21:08:33 -07:00
David Wood
3fc7ab2373
Merged migrated compile-fail tests and ui tests. Fixes #46841. 2018-08-14 11:12:09 +02:00