Skip to content

Type mismatch between associated type and concrete type which are the same type. #34430

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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. T-types Relevant to the types 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
@fmease fmease added A-type-system Area: Type system T-types Relevant to the types team, which will review and decide on the PR/issue. and removed A-type-system Area: Type system labels Dec 21, 2024
# for free to join this conversation on GitHub. Already have an account? # 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. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests