Distinguish between constants and bindings in patterns

[matklad]

In rust, a pattern like x in match foo() { x => () } might mean one of two things:

• an cont x: i32 = 92, in which case we match against a literal constant.
• a fresh binding, in which case we should bind the name x

The rule for distinguishing the two cases is: "if there's a constant in scope, the pattern is constant, otherwise it is a binding". We currently treat all such cases as bindings.

I think this should be fixed here:

https://github.com/rust-analyzer/rust-analyzer/blob/ad63fbe61a2e024bab8baadc22863a0795d20a95/crates/ra_hir/src/expr/scope.rs#L90-L100

However, we can't do that with the current code, because we don't have access to Resolver there, and so can't check if a name binds to a constant already. The problem with using Resolver here is that resolver already knows about expression scopes.... So looks like we should use ModuleItemMap directly instead.

We also should record the fact that binding is a constant somewhere. A table in InferenceResult seems like a good place for this:

https://github.com/rust-analyzer/rust-analyzer/blob/ad63fbe61a2e024bab8baadc22863a0795d20a95/crates/ra_hir/src/ty/infer.rs#L110-L123

This also makes me think that maybe we should redo our Expr infra and resolve expressions during lowering, and not duting type inference....

[flodiebold]

This also makes me think that maybe we should redo our Expr infra and resolve expressions during lowering, and not during type inference....

Agreed, we're probably unnecessarily lazy in this case... (though some paths of course can only be resolved during inference, so we need to handle partially resolved paths similarly to how rustc does it (that doesn't affect this issue though, one-element paths should always be resolvable during lowering))

[matklad]

One thing that is easier with the current setup is that we can get scopes for completion easily.

I think the query setup we want is

lower_with_scopes(def) -> (Body, Scopes)
lower(def) -> Body

such that we don't remmeber scopes unnceseccary, but also don't repeat special logic for completion

[matklad]

Hm, I've looked recently into this and an (simpler?) idea I had is to add a targeted hack somewhere around here:

https://github.com/rust-analyzer/rust-analyzer/blob/1b73abd1c3c9185f4a1f62c5e657e07daf3d4774/crates/ra_hir_ty/src/infer/pat.rs#L114

Check if the pattern "resolves" and, if it does, just substitute it with a Pat::Path, and then procede as usual.

[flodiebold]

I think it would still mean that that name would resolve to the pattern inside the match arm 😕
E.g. in
match ... { None => None, ... } the second None would wrongly have the type of the match expression.