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

Associated types bounds seem to be ignored in generic impls #50237

Open
glandium opened this issue Apr 25, 2018 · 2 comments
Open

Associated types bounds seem to be ignored in generic impls #50237

glandium opened this issue Apr 25, 2018 · 2 comments
Labels
A-trait-system Area: Trait system C-bug Category: This is a bug. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@glandium
Copy link
Contributor

Consider the following code:

#![crate_type="lib"]

use std::marker::PhantomData;

trait Foo {
    type Type: Qux;
}

struct Bar<T>(PhantomData<T>);

trait Qux {}

impl<T: Foo> From<T::Type> for Bar<T> {
    fn from(t: T::Type) -> Self {
        Bar(PhantomData)
    }
}

This fails to build with:

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

This implies the compiler thinks T::Type might be Bar<T>, but because of the Qux bound, and the fact that there is no impl<T> Qux for Bar<T> {}, it's not possible.

In fact, doing some handholding works: impl<T: Foo<Type=U>, U: Qux> From<U> for Bar<T> yields no error and is equivalent, albeit unnecessarily verbose.

@pietroalbini pietroalbini added A-trait-system Area: Trait system T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Apr 26, 2018
@rkarp
Copy link
Contributor

rkarp commented May 5, 2018

This might be related to #24159, at least the workaround to make the compiler happy is the same.

@Enselic
Copy link
Member

Enselic commented Nov 17, 2023

Triage: Seems different from #24159 because that one did not reproduce with chalk, whereas the reproducer in this issue does still reproduce with rustc +nightly -Ztrait-solver=next (rustc 1.76.0-nightly (a577704 2023-11-16))

@Enselic Enselic added T-types Relevant to the types team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system 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

4 participants