Implementing From for associated type results in confusing error

[oliver-giersch]

Disclaimer: I am not sure if this an actual bug or rather a diagnostic issue.

The following simplified code

use std::str::FromStr;

type BoolErr = <bool as FromStr>::Err;

struct Error(BoolErr);

impl From<BoolErr> for Error {
    fn from(err: BoolErr) -> Self {
        Self(err)
    }
}

Playground

Produces the following incorrect/confusing error message on both stable and nigthly:

error[E0119]: conflicting implementations of trait `std::convert::From<Error>` for type `Error`:
 --> src/lib.rs:7:1
  |
7 | impl From<BoolErr> for Error {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `core`:
          - impl<T> From<T> for T;

I encountered this issue when I wanted to wrap the result returned by str::parse for a type from crate A which uses an error type from another crate B, which I did not want to depend on and import directly. I am aware that using an associated type here has implications for backwards compatibility, but in this case this is actually desirable I think, since I only want to forward the result into my custom error type, even if the concrete error type in crate A/B changes.

[smmoosavi]

This is a bug.

When it happens

When type is an associated type of a trait, and the trait is implemented in another crate. if the trait is implemented in the same crate, it works fine. Also if types are used directly, it works fine.

playground 1 use ParseBoolError directly and has no error
playground 2 use type from trait and have the error

ParseBoolError and BoolErr are equal.

type BoolErr = <bool as FromStr>::Err;
assert_eq!(TypeId::of::<BoolErr>(), TypeId::of::<ParseBoolError>());

I have created a new repository that showcases another example of the same error.

type OtherDuration = <other::Systick as other::Monotonic>::Duration;
type OtherInstant = <other::Systick as other::Monotonic>::Instant;

impl FromTime for OtherDuration {}
impl FromTime for OtherInstant {}

[QuineDot]

Duplicates:

• Using associated types on concrete types as parameters for trait impls causes incorrect type resolution #37832
• Implementations conflict when using associated type across crates #51445
• Associated types from foreign trait impls are considered as conflicting with every other type #85898
• Trait impls using associated types of a type defined in another crate cause confusing "conflicting implementations" error although implementations don't actually conflict #102958
• False conflicting implementations error with associated types #109559

[lcnr]

FOr an explanation of the affected issue, see #99940 (comment)