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 mismatch between associated type and concrete type which are the same type. #34430

Open
canndrew opened this issue Jun 23, 2016 · 9 comments
Labels
A-trait-system Area: Trait system A-type-system Area: Type system C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@canndrew
Copy link
Contributor

Trying to build the following code:

trait WithLifetime<'a> {
    type Type;
}

struct Foo;

enum FooRef {}

impl<'a> WithLifetime<'a> for FooRef {
    type Type = &'a Foo;
}

fn wub<T, F>(f: F)
    where T: for<'a> WithLifetime<'a>,
          F: for<'a> FnOnce(&'a Foo) -> <T as WithLifetime<'a>>::Type
{
}

fn main() {
    wub::<FooRef, _>(|foo| foo)
}

Gives the error:

foo.rs:20:28: 20:31 error: mismatched types:
 expected `<FooRef as WithLifetime<'a>>::Type`,
    found `&'a Foo`
(expected associated type,
    found &-ptr) [E0308]
foo.rs:20     wub::<FooRef, _>(|foo| foo)
                                     ^~~

However <FooRef as WithLifetime<'a>>::Type and &'a Foo are the same type. And the compiler should be able to see that.

@eddyb
Copy link
Member

eddyb commented Jun 23, 2016

cc @arielb1 @nikomatsakis Which issue is this a dupe of? I never can find which one is canonical.

@canndrew I believe is this is the usual "associated type projection under HRTB just doesn't get normalized" which is a limitation of the current implementation.
@soltanmm, IIRC, tried to approach a solution, but I haven't heard from them in a while.

@canndrew
Copy link
Contributor Author

canndrew commented Jun 23, 2016

Is there any workaround that you know of to trick it into normalising?

Edit: Welp, explicitly specifying the return type of the closure makes it ICE.

@soltanmm
Copy link

@eddyb I'm still here! I've just also been... everywhere else. There's a lot of 'everywhere else'...

Lazy normalization AFAIK should cover this, and is WIP.

@Mark-Simulacrum
Copy link
Member

@eddyb Is this #30867? It looks similar...

@nikomatsakis nikomatsakis added A-trait-system Area: Trait system A-type-system Area: Type system labels May 8, 2017
@nikomatsakis
Copy link
Contributor

Related, certainly. In general we don't really normalize under binders (Yet! Coming Soon, I hope!) which leads to a lot of problems.

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 25, 2017
@dylanede
Copy link
Contributor

What's the status of this issue at the moment? I seem to run into it a couple of times a year.

@steveklabnik
Copy link
Member

Triage: error message is different now:

   Compiling playground v0.0.1 (/playground)
error[E0271]: type mismatch resolving `for<'a> <[closure@src/main.rs:20:22: 20:31] as std::ops::FnOnce<(&'a Foo,)>>::Output == <FooRef as WithLifetime<'a>>::Type`
  --> src/main.rs:20:5
   |
20 |     wub::<FooRef, _>(|foo| foo)
   |     ^^^^^^^^^^^^^^^^ expected &Foo, found associated type
   |
   = note: expected type `&Foo`
              found type `<FooRef as WithLifetime<'_>>::Type`
note: required by `wub`
  --> src/main.rs:13:1
   |
13 | / fn wub<T, F>(f: F)
14 | |     where T: for<'a> WithLifetime<'a>,
15 | |           F: for<'a> FnOnce(&'a Foo) -> <T as WithLifetime<'a>>::Type
16 | | {
17 | | }
   | |_^

error: aborting due to previous error

@heckad
Copy link
Contributor

heckad commented Aug 16, 2020

Are there any plans to fix this?

@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
@kadiwa4
Copy link
Contributor

kadiwa4 commented Aug 22, 2023

Compiles since 1.56.0.

@fmease fmease added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system A-type-system Area: Type system C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests