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

#![feature(type_alias_enum_variants)]: Unit variant pattern through a type alias to generic enum requires type annotations #61801

Closed
Centril opened this issue Jun 13, 2019 · 2 comments · Fixed by #61825
Labels
A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jun 13, 2019

The following, which I expect to work, fails to infer the type of OptAlias::None:

#![feature(type_alias_enum_variants)]

enum Option<T> {
    None,
    Some(T),
}

type OptAlias<T> = Option<T>;

fn work_on_alias(x: OptAlias<u8>) {
    match x {
        OptAlias::None => (), //~ ERROR type annotations needed
        _ => (),
    }
}

In HIR, OptAlias::None should correspond to:

PatKind::Path(
    QPath::TypeRelative(_, P(
        PathSegment { res: Some(
            Res::Def(DefKind::Ctor(CtorOf::Variant, CtorKind::Const))
        ), .. }
    ))
)

However, if we change the snippet to:

#![feature(type_alias_enum_variants)]

enum Option<T> {
    None,
    Some(T),
}

type OptAlias<T> = Option<T>;

fn work_on_alias(x: OptAlias<u8>) {
    match x {
        OptAlias::None {} => (), // Note the changed pattern.
        _ => (),
    }
}

it all works out fine.

I also tested changing None to a tuple variant and that works also.

cc @petrochenkov @eddyb @alexreg

cc #61682

@Centril Centril added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-inference Area: Type inference C-bug Category: This is a bug. labels Jun 13, 2019
@Centril
Copy link
Contributor Author

Centril commented Jun 13, 2019

It might be a good idea to trace the difference between check_pat_path and check_pat_tuple_struct because they look relatively similar and yet they behave differently in terms of inference.

@petrochenkov
Copy link
Contributor

petrochenkov commented Jun 13, 2019

Value (Path/Path()) and type (Path {}) namespaces execute very different logic for type inference (resolve_ty_and_res_ufcs/instantiate_value_path vs check_struct_path).
It's quite possible that there are intended and unintended observable differences (not necessarily specific to feature(type_alias_enum_variants)).

check_pat_path and check_pat_tuple_struct

Rather check_pat_path and check_pat_struct.
(check_pat_tuple_struct is the same "value" case as check_pat_path.)

bors added a commit that referenced this issue 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
Centril added a commit to Centril/rust that referenced this issue 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 issue 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 issue 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 issue 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
bors added a commit that referenced this issue 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
2 participants