Unrelated trait bounds prevents generic types to be inferred in function call.

[RikardLegge]

I tried this code (Playground):

pub struct Type {}
pub struct Unrelated<T>(T);

impl From<Unrelated<Type>> for Unrelated<()> {
    fn from(_: Unrelated<Type>) -> Self {
        todo!()
    }
}

fn type_ok<T>() {
    let _: Type = type_constraint(Type {});
}

fn type_wrong_type_parameter<T>()
where
    Unrelated<T>: Into<Unrelated<()>>,
{
    let _: Type = type_constraint(Type {});
    //.           --------------- ^^^^^^^ expected type parameter `T`, found struct `Type`
    //            |
    //            arguments to this function are incorrect
}

fn type_constraint<Q>(_: Q) -> Q
where
    Unrelated<Q>: Into<Unrelated<()>>,
{
    unimplemented!()
}

Another example with the same problem caused associated types: Example 2 Playground.

I expected to see this happen: The example should compile and the ignored variables _ on the left hand side has type Type in the examples.

Instead, this happened: Only the unbounded function compiles. The functions with the added trait bounds causes a compile time error. The three simplest ways of resolving the problem are:

1. Removing the trait bounds from either type_wrong_type_parameter or type_constraint. Might not be possible.
2. Replacing Unrelated<T> with T in the trait bounds. This is usually not a solution either.
3. Adding an explicit type to the function call type_constraint::<Type>. This allows the problem to in most cases be side-stepped.

If the problem is that the function want's to resolve T to a known type, the relation between the unused generic variable T and the function call is still not obvious.

Meta

Tested on both the stable and nightly compiler:

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-apple-darwin
release: 1.64.0
LLVM version: 14.0.6

rustc 1.66.0-nightly (a6b7274a4 2022-10-10)
binary: rustc
commit-hash: a6b7274a462829f8ef08a1ddcdcec7ac80dbf3e1
commit-date: 2022-10-10
host: x86_64-apple-darwin
release: 1.66.0-nightly
LLVM version: 15.0.2

Error output

Compiling playground v0.0.1 (/playground)
error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
  --> src/lib.rs:18:35
   |
14 | fn type_wrong_type_parameter<T>()
   |                              - this type parameter
...
18 |     let _: Type = type_constraint(Type {});
   |                   --------------- ^^^^^^^ expected type parameter `T`, found struct `Type`
   |                   |
   |                   arguments to this function are incorrect
   |
   = note: expected type parameter `T`
                      found struct `Type`
note: function defined here
  --> src/lib.rs:24:4
   |
24 | fn type_constraint<Q>(_: Q) -> Q
   |    ^^^^^^^^^^^^^^^    ----

error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
  --> src/lib.rs:18:19
   |
14 | fn type_wrong_type_parameter<T>()
   |                              - this type parameter
...
18 |     let _: Type = type_constraint(Type {});
   |            ----   ^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `Type`, found type parameter `T`
   |            |
   |            expected due to this
   |
   = note:      expected struct `Type`
           found type parameter `T`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to 2 previous errors

[AstralSorceress]

triage: Still an issue on stable and nightly.

Also ran into this with const generics: (playground)

[addisoncrump]

I similarly encounter this with associated types.

Doesn't compile:

struct A;
struct B;
struct C;

impl From<B> for A {
    fn from(value: B) -> Self {
        A
    }
}

impl From<C> for A {
    fn from(value: C) -> Self {
        A
    }
}

trait ATTrait {
    type AT;
}

fn thing<T>()
where
    T: ATTrait,
    A: From<T::AT>,
{
    A::from(B);
    A::from(C);
}

Does compile:

struct A;
struct B;
struct C;

impl From<B> for A {
    fn from(value: B) -> Self {
        A
    }
}

impl From<C> for A {
    fn from(value: C) -> Self {
        A
    }
}

trait ATTrait {
    type AT;
}

fn thing<T>()
where
    T: ATTrait,
    A: From<T::AT> + From<B>,
{
    A::from(B);
    A::from(C);
}

So, curiously, not only is it that the inference fails, but merely specifying one of the concrete types causes it to work again.

[compiler-errors]

So, curiously, not only is it that the inference fails, but merely specifying one of the concrete types causes it to work again.

Adding a second where clause introduces a choice to the trait solver which forces inference ambiguity until long enough that the A::from(B) expression can type check the B subexpression (and similarly for C). Adding any A: From<_> where clause would work here.

[addisoncrump]

So, is this intended behaviour? Surely not.

[compiler-errors]

It's not intended behavior, but it's certainly not something that we can easily fix since an overwhelming amount of code relies on eager where-clause preference.