Skip to content

Compilation error when implementing From using a concrete associated type from another crate #109885

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
stormshield-kg opened this issue Apr 3, 2023 · 3 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) A-coherence Area: Coherence C-bug Category: This is a bug. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@stormshield-kg
Copy link

I have the following files from 2 crates:

// dep/src/lib.rs

pub trait Wrapped {
    type WrappedType;
}

pub struct W3;
pub struct S3;

impl Wrapped for S3 {
    type WrappedType = W3;
}
// main/src/lib.rs

use dep::Wrapped;

struct W;
struct S;

impl Wrapped for S {
    type WrappedType = W;
}

struct W2;
struct S2;

impl Wrapped for S2 {
    type WrappedType = W2;
}

// This works
impl From<<S2 as Wrapped>::WrappedType> for W {
    fn from(value: W2) -> Self {
        todo!()
    }
}

// This doesn't work
impl From<<dep::S3 as Wrapped>::WrappedType> for W {
    fn from(value: dep::W3) -> Self {
        todo!()
    }
}

Currently I have the following error:

error[E0119]: conflicting implementations of trait `std::convert::From<W>` for type `W`
  --> main/src/lib.rs:23:1
   |
23 | impl From<<dep::S3 as Wrapped>::WrappedType> for W {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T> std::convert::From<T> for T;

I expected that <dep::S3 as Wrapped>::WrappedType would be resolved to a single type like <S2 as Wrapped>::WrappedType>, and that the code would compile.

Context

I'm using dep::S3 and W as the inputs of a proc-macro, and I would like to generate impl From<dep::W3> for W inside the proc-macro, but without mentioning dep::W3 explicitely.

Meta

rustc --version --verbose:

rustc 1.70.0-nightly (0599b6b93 2023-04-01)
binary: rustc
commit-hash: 0599b6b931816ab46ab79072189075f543931cbd
commit-date: 2023-04-01
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0
@stormshield-kg stormshield-kg added the C-bug Category: This is a bug. label Apr 3, 2023
@clubby789
Copy link
Contributor

clubby789 commented Apr 3, 2023

This might be related to #102728, as

the orphan check does not look into associated types as it has to run before we are able to do so.

@stormshield-kg
Copy link
Author

Since the type W is local and explicit, there shouldn't be any problem with the orphan rule check.

@clubby789
Copy link
Contributor

What I mean is that the conflicting impls check also likely runs before looking into associated types is possible

@fmease fmease added A-associated-items Area: Associated items (types, constants & functions) T-types Relevant to the types team, which will review and decide on the PR/issue. A-coherence Area: Coherence labels Sep 28, 2024
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-coherence Area: Coherence C-bug Category: This is a bug. 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

5 participants