Skip to content
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

Merged
merged 2 commits into from
Jun 15, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jun 14, 2019

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 14, 2019
@Centril
Copy link
Contributor Author

Centril commented Jun 14, 2019

@bors try

This might possibly be a perf improvement?

@bors
Copy link
Contributor

bors commented Jun 14, 2019

⌛ Trying commit 065151f with merge 330c85d...

bors added a commit that referenced this pull request Jun 14, 2019
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
@bors
Copy link
Contributor

bors commented Jun 14, 2019

☀️ Try build successful - checks-travis
Build commit: 330c85d

@petrochenkov
Copy link
Contributor

The gist of the problem here was that resolve_ty_and_res_ufcs was called twice which is apparently no good...

This looks like a fallout from implementation default binding modes.
It was called once the last time I rewrote that code.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 14, 2019

📌 Commit 065151f has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 14, 2019
Centril added a commit to Centril/rust that referenced this pull request Jun 14, 2019
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
Centril added a commit to Centril/rust that referenced this pull request Jun 14, 2019
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
Centril added a commit to Centril/rust that referenced this pull request Jun 14, 2019
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
Centril added a commit to Centril/rust that referenced this pull request Jun 14, 2019
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
@Centril
Copy link
Contributor Author

Centril commented Jun 15, 2019

@bors p=101

Trying this one out to see if the bors problems go away.

@bors
Copy link
Contributor

bors commented Jun 15, 2019

⌛ Testing commit 065151f with merge 9f8cd9d...

bors added a commit that referenced this pull request Jun 15, 2019
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
@bors
Copy link
Contributor

bors commented Jun 15, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrochenkov
Pushing 9f8cd9d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 15, 2019
@bors bors mentioned this pull request Jun 15, 2019
@bors bors merged commit 065151f into rust-lang:master Jun 15, 2019
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #61825!

Tested on commit 9f8cd9d.
Direct link to PR: #61825

🎉 rls on linux: test-fail → test-pass (cc @Xanewok, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jun 15, 2019
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).
@pietroalbini
Copy link
Member

@bors treeclosed-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
5 participants