-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
type_alias_enum_variants: fix #61801; allow a path pattern to infer #61825
Conversation
@bors try This might possibly be a perf improvement? |
type_alias_enum_variants: fix #61801; allow a path pattern to infer Fix #61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc #61682 cc #49683
☀️ Try build successful - checks-travis |
This looks like a fallout from implementation default binding modes. @bors r+ rollup |
📌 Commit 065151f has been approved by |
type_alias_enum_variants: fix rust-lang#61801; allow a path pattern to infer Fix rust-lang#61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc rust-lang#61682 cc rust-lang#49683
type_alias_enum_variants: fix rust-lang#61801; allow a path pattern to infer Fix rust-lang#61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc rust-lang#61682 cc rust-lang#49683
type_alias_enum_variants: fix rust-lang#61801; allow a path pattern to infer Fix rust-lang#61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc rust-lang#61682 cc rust-lang#49683
type_alias_enum_variants: fix rust-lang#61801; allow a path pattern to infer Fix rust-lang#61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc rust-lang#61682 cc rust-lang#49683
@bors p=101 Trying this one out to see if the bors problems go away. |
type_alias_enum_variants: fix #61801; allow a path pattern to infer Fix #61801. Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression. Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...) The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler. r? @petrochenkov cc @eddyb @alexreg cc #61682 cc #49683
☀️ Test successful - checks-travis, status-appveyor |
Tested on commit rust-lang/rust@9f8cd9d. Direct link to PR: <rust-lang/rust#61825> 🎉 rls on linux: test-fail → test-pass (cc @Xanewok, @rust-lang/infra).
@bors treeclosed- |
Fix #61801.
Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a
match
expression.Similar issues may exist for
let
statements but I don't know how to test for that sincePhantomData<T>
is necessary...)The gist of the problem here was that
resolve_ty_and_res_ufcs
was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler.r? @petrochenkov
cc @eddyb @alexreg
cc #61682
cc #49683