Uh oh!
There was an error while loading. Please reload this page.
Separate bindings from other patterns in HIR - #33929
Conversation
| /// referred to as simply `T::CONST`, in which case they will end up as | ||
| /// PatKind::Path, and the resolver will have to sort that out. | ||
| /// A path pattern written in qualified form, i.e. `<T as Trait>::CONST` or `<T>::CONST`. | ||
| /// Such patterns can only refer to associated constants at the moment. |
There was a problem hiding this comment.
Oh, it slipped from the later unpublished part of the patch.
The old comment basically says "yep, it's an associated constant" while it's only a syntactic form - qualified path, it can resolve to a constant, but it also can resolve to any other associated item - a method or an associated type (?), and passes working on HIR should be ready to deal with it.
There was a problem hiding this comment.
s/refer/legally refer/ would probably be better
There was a problem hiding this comment.
Oh, it slipped from the later unpublished part of the patch.
Thought so. I'd take it out of this PR, it seems out of place.
eddyb
commented
May 28, 2016
@petrochenkov About path lowering, @nikomatsakis and I were discussion #33596 and we agreed that the proper solution involves having something like |
petrochenkov
commented
May 28, 2016
Updated. |
eddyb
commented
May 28, 2016
@bors r+ |
bors
commented
May 28, 2016
📌 Commit ae999e9 has been approved by |
bors
commented
May 29, 2016
⌛ Testing commit ae999e9 with merge d190a99... |
bors
commented
May 29, 2016
💔 Test failed - auto-linux-64-opt-rustbuild |
arielb1
commented
May 29, 2016
@bors retry |
bors
commented
May 30, 2016
Separate bindings from other patterns in HIR Now when name resolution is done on AST, we can avoid dumping everything that looks like an identifier into `PatKind::Ident` in HIR. `hir::PatKind::Ident` is removed, fresh bindings are now called `hir::PatKind::Binding`, everything else goes to `hir::PatKind::Path`. I intend to do something with `PatKind::Path`/`PatKind::QPath` as well using resolution results, but it requires some audit and maybe some deeper refactoring of relevant resolution/type checking code to do it properly. I'm submitting this part of the patch earlier to notify interested parties that I'm working on this. cc @jseyfried r? @eddyb
bors
commented
May 30, 2016
Improvements to pattern resolution + some refactoring Continuation of #33929 First commit is a careful rewrite of `resolve_pattern`, pattern path resolution and new binding creation logic is factored out in separate functions, some minor bugs are fixed. Also, `resolve_possibly_assoc_item` doesn't swallow modules now. Later commits are refactorings, see the comment descriptions. I intend to continue this work later with better support for `Def::Err` in patterns in post-resolve stages and cleanup of pattern resolution code in type checker. Fixes#32086Fixes#34047 ([breaking-change]) Fixes#34074 cc @jseyfried r? @eddyb
Now when name resolution is done on AST, we can avoid dumping everything that looks like an identifier into
PatKind::Identin HIR.hir::PatKind::Identis removed, fresh bindings are now calledhir::PatKind::Binding, everything else goes tohir::PatKind::Path.I intend to do something with
PatKind::Path/PatKind::QPathas well using resolution results, but it requires some audit and maybe some deeper refactoring of relevant resolution/type checking code to do it properly.I'm submitting this part of the patch earlier to notify interested parties that I'm working on this.
cc @jseyfried
r? @eddyb