Skip to content

associated type not normalized when a where-clause is present #28895

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

Open
arielb1 opened this issue Oct 7, 2015 · 8 comments
Open

associated type not normalized when a where-clause is present #28895

arielb1 opened this issue Oct 7, 2015 · 8 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system C-bug Category: This is a bug. P-low Low priority T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@arielb1
Copy link
Contributor

arielb1 commented Oct 7, 2015

Affected Versions

At least 1.3, 1.4, rustc 1.5.0-nightly (11a612795 2015-10-04)

STR

trait Foo { type Bar; }
impl<T> Foo for T { type Bar = u64; }
fn foo<T>() -> <T as Foo>::Bar
    where T: Foo // <- the code compiles if this is removed
{ 1 }
fn main() {}

Expected Result

the code should compile

Actual Result

<anon>:7:14: 7:15 error: mismatched types:
 expected `<T as Foo>::Bar`,
    found `_`
(expected associated type,
    found integral variable) [E0308]
<anon>:7     x = Some(1);
                      ^

cc @nikomatsakis

@arielb1 arielb1 added the A-trait-system Area: Trait system label Oct 7, 2015
@arielb1
Copy link
Contributor Author

arielb1 commented Oct 7, 2015

The root cause is that selection picks the where-clause candidate over any impl candidate, and this does not allow projection to make progress. This looks to be hard to fix.

@nikomatsakis
Copy link
Contributor

Yes, this is to some extent a known limitation and the "expected result", but I would still classify it as a bug.

@brson brson added T-lang Relevant to the language team, which will review and decide on the PR/issue. I-wrong A-associated-items Area: Associated items (types, constants & functions) P-low Low priority labels Mar 23, 2017
@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. and removed I-wrong labels Jul 24, 2017
@gmorenz
Copy link

gmorenz commented Jan 20, 2020

(Note: Deleted and reposted since I screwed up the first version, and realized I could minimize it more)

I hit this case while trying to work around #68375 - I'm pretty sure it's the same bug

pub trait Data {
    type Elem;
}

pub struct ViewRepr<A>(A);

impl<'a, A> Data for ViewRepr<&'a A> {
    type Elem = A;
}

type ArrayBase<S> = ArrayBaseInner<S, <S as Data>::Elem>;
pub struct ArrayBaseInner<S: Data<Elem = Elem>, Elem> {
    ptr: *mut Elem,
    d: S,
}

fn std1d<'a>(_: ArrayBase<ViewRepr<&'a f64>>) {}

fn map_axis<'a, F>(f: F)
where 
    F: FnMut(ArrayBase<ViewRepr<&'a f64>>)
{}

fn std() {
    map_axis(std1d);
}
error[E0631]: type mismatch in function arguments
  --> test.rs:25:14
   |
17 | fn std1d<'a>(_: ArrayBase<ViewRepr<&'a f64>>) {}
   | --------------------------------------------- found signature of `for<'a> fn(ArrayBaseInner<ViewRepr<&'a f64>, <ViewRepr<&'a f64> as Data>::Elem>) -> _`
18 | 
19 | fn map_axis<'a, F>(f: F)
   |    --------
20 | where 
21 |     F: FnMut(ArrayBase<ViewRepr<&'a f64>>)
   |        ----------------------------------- required by this bound in `map_axis`
...
25 |     map_axis(std1d);
   |              ^^^^^ expected signature of `fn(ArrayBaseInner<ViewRepr<&f64>, f64>) -> _`

@RustyYato
Copy link
Contributor

RustyYato commented Jan 20, 2020

Nope, you have a return value in std1d but not in the where clause for map_axis

@gmorenz
Copy link

gmorenz commented Jan 20, 2020

Oops, you're right, minification mistake. Fixed that above, it doesn't substantially change the error message.

@RustyYato
Copy link
Contributor

@gmorenz this is because of the lifetime parameter. Because the associated type could depend on the choice of lifetime parameter, it doesn't get normalized.

That does seem related to this Issue.

@Spoonbender
Copy link

Triage: no change

@Dylan-DPC
Copy link
Member

Dylan-DPC commented Aug 28, 2024

Current output:

error[E0308]: mismatched types
 --> src/main.rs:7:3
5 | fn foo<T>() -> <T as Foo>::Bar
  |                --------------- expected `<T as Foo>::Bar` because of return type
6 |     where T: Foo // <- the code compiles if this is removed
7 | { 1 }
  |   ^ expected associated type, found integer
  |
  = note: expected associated type `<T as Foo>::Bar`
                        found type `{integer}`
help: consider constraining the associated type `<T as Foo>::Bar` to `{integer}`
  |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system C-bug Category: This is a bug. P-low Low priority T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants