Skip to content

Associated types are not resolved in the IDE layer #5003

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

Closed
lnicola opened this issue Jun 23, 2020 · 6 comments · Fixed by #8283
Closed

Associated types are not resolved in the IDE layer #5003

lnicola opened this issue Jun 23, 2020 · 6 comments · Fixed by #8283
Labels
A-nameres name, path and module resolution A-ty type system / type inference / traits / method resolution S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@lnicola
Copy link
Member

lnicola commented Jun 23, 2020

Like the T::S here:

trait D {}

trait Foo {
    type S;
}

trait Bar<T>
where
    T: Foo,
    T::S: D,
{
}

fn main() {}

CC #4991

Another one:

trait Foo {
    type Bar;

    fn foo(_: Self::Bar);
}

struct S;

impl Foo for S {
    type Bar = i32;

    fn foo(_: Self::Bar) {
        todo!()
    }
}
@lnicola lnicola added the A-ty type system / type inference / traits / method resolution label Jun 23, 2020
@flodiebold
Copy link
Member

Not sure what you mean by "not resolved" here -- as far as I can see, e.g. within methods in Bar we can call methods of D on any T::S.

@lnicola
Copy link
Member Author

lnicola commented Jul 4, 2020

Hmm, that's interesting. Yeah, it seems to work, but T::S shows up as unresolvedReference:

image

@lnicola

This comment has been minimized.

@flodiebold
Copy link
Member

We don't handle this correctly in the IDE layer, that's true. Resolving T::S to the associated type happens during type lowering, which the IDE layer doesn't really access yet.

The type hint is correct, though we might consider displaying it differently. Since T::S doesn't normalize to any concrete type, it's represented as an associated type placeholder, which looks like this; but maybe we should display it as the projection <T as Foo>::S instead.

Actually both of these are a bit related to the type IR I've been working on slowly for a while, because I think it might also be the correct way to represent types for the IDE layer -- it would have T::S resolved, and it wouldn't have a representation of associated type placeholders (instead going back to it would convert them to projections)... 🤔

@mouse07410
Copy link

Thank you for working on this! Any idea what the time-frame for the incremental solution steps might be?

@lnicola
Copy link
Member Author

lnicola commented Oct 28, 2020

#6387 fixed #5003 (comment), CC @bnjjj:

image

@flodiebold flodiebold added the S-unactionable Issue requires feedback, design decisions or is blocked on other work label Dec 21, 2020
@flodiebold flodiebold changed the title Associated types implied by trait bounds are not resolved Associated types are not resolved in the IDE layer Dec 22, 2020
@Veykril Veykril added the A-nameres name, path and module resolution label Apr 1, 2021
@bors bors bot closed this as completed in 5ef0c7a Apr 1, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-nameres name, path and module resolution A-ty type system / type inference / traits / method resolution S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants