]> git.lizzy.rs Git - rust.git/commit
Suggest using a qualified path in patterns with inconsistent bindings
authorJakub Adam Wieczorek <jakub.adam.wieczorek@gmail.com>
Fri, 9 Aug 2019 09:43:26 +0000 (09:43 +0000)
committerJakub Adam Wieczorek <jakub.adam.wieczorek@gmail.com>
Sat, 10 Aug 2019 21:09:53 +0000 (21:09 +0000)
commit53a6304c2a431ae97c3b584066804c6acd667541
tree311475e575eea261586d23be44d709bd1158c5e6
parent9703ef666123c465f784e294b5b24d6d35a37745
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.
src/librustc_resolve/diagnostics.rs
src/librustc_resolve/late.rs
src/librustc_resolve/lib.rs
src/test/ui/resolve/resolve-inconsistent-names.rs
src/test/ui/resolve/resolve-inconsistent-names.stderr