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

Error message for accessing associated type on concrete type is misleading #92499

Open
euclio opened this issue Jan 2, 2022 · 4 comments
Open
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@euclio
Copy link
Contributor

euclio commented Jan 2, 2022

I tried this code:

type Foo = u8::AssocTy;

trait Bar {
  type AssocTy;
}

impl Bar for u8 {
  type AssocTy = u8;
}

I expected to see this happen: Compiler emits an error reporting that I cannot access associated types from concrete types, and must use fully-qualified syntax to specify the desired trait.

Instead, this happened: Compiler emits an error reporting that AssocTy is ambiguous:

error[E0223]: ambiguous associated type
 --> src/main.rs:1:12
  |
1 | type Foo = u8::AssocTy;
  |            ^^^^^^^^^^^ help: use fully-qualified syntax: `<u8 as Trait>::AssocTy`

This made me wonder why it's ambiguous, since there's only one trait implemented for u8 that has that type name. The suggestion only added more confusion, because it only shows a placeholder trait name instead of listing the actual names of potential traits. I thought that maybe there was another trait implemented for u8 that used the same associated type name, until I realized that you must specify the trait name when accessing an associated type from a concrete type.

Note that this error message is also emitted for non-existent associated types, and even for types that are specified with invalid syntax. See more examples in this UI test.

Related to #59225.

Meta

rustc --version --verbose:

1.59.0-nightly

(2022-01-01 c145692254e86974941f)
@euclio euclio added the C-bug Category: This is a bug. label Jan 2, 2022
@hadilq
Copy link

hadilq commented Apr 12, 2022

I have a similar problem that made me nut, because I need to wrap the errors to be able to track them back! This is my case if you ask:

use std::result::Result;
use std::result::Result::Err;

pub trait Service {
    type Error;

    fn run() -> Result<(), Self::Error>;
}

enum ErrorWrapper {
    ServiceError(Service::Error)
}

struct ServiceImpl;

struct ServiceImplError;

impl Service for ServiceImpl {
    type Error = ServiceImplError;

    fn run() -> Result<(), Self::Error> {
        Err(ServiceImplError)
    }
}

fn main() -> Result<(), ErrorWrapper> {
    ServiceImpl::run().map_err(|e| ErrorWrapper::ServiceError(e))
}

It raises

error[E0223]: ambiguous associated type
  --> src/main.rs:11:18
   |
11 |     ServiceError(Service::Error)
   |                  ^^^^^^^^^^^^^^ help: use fully-qualified syntax: `<Type as Service>::Error`

I need the Service trait because I'm injecting the implementation later, but if you think there's a simple solution to this please let me know.
Anyway, I didn't touch the Rust compiler before, but if you think I can help to fix this, just let me know.

@tavianator
Copy link
Contributor

@hadilq In your case I think you want

enum ErrorWrapper<T: Service> {
    ServiceError(T::Error)
}

@hadilq
Copy link

hadilq commented Apr 13, 2022

Thanks @tavianator, yes it solved mine! Now I think maybe I could ask it in StackOverflow!

@euclio
Copy link
Contributor Author

euclio commented Aug 1, 2022

@rustbot label A-diagnostics

@rustbot rustbot added the A-diagnostics Area: Messages for errors, warnings, and lints label Aug 1, 2022
@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints 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
Development

No branches or pull requests

5 participants