Cycle detected when using associated type bounds in super trait

[tage64]

I don't know if this is a bug or expected behaviour. But I'm encountering the following error when compiling the following code.

#![feature(associated_type_bounds)]

trait A {
    type T;
}

trait B: A<T: B> {}

error[E0391]: cycle detected when computing the supertraits of `B`
 --> src/main.rs:6:15
  |
6 | trait B: A<T: B> {}
  |               ^
  |
  = note: ...which again requires computing the supertraits of `B`, completing the cycle
note: cycle used when collecting item types in top-level module
 --> src/main.rs:6:1
  |
6 | trait B: A<T: B> {}
  | ^^^^^^^^^^^^^^^^

But if I merge the traits A and B into the trait C it works.

trait C {
    type T: C;
}

I think the first example should work as good as the second since the trait C is only split into two traits A and B with same functionality.

[Centril]

When we write:

trait B: A<T: B> {}

this is equivalent to:

trait B
where
    Self: A<T: B>
{}

which is equivalent to:

trait B
where
    Self: A,
    <Self as A>::T: B,
{}

This results in an error:

error[E0277]: the trait bound `<<Self as A>::T as A>::T: B` is not satisfied

One might think that this should compile because <<Self as A>::T as A>::T: B should flow from the mere fact that Self::T: B holds which should hold by Self: B. However, the compiler isn't smart enough to take these implied bounds into account. When it comes to the special case of type T: C;, the compiler is able to do that however.

What is curious here is that rather than getting the error message about "not satisfied", we are getting a cycle error. cc @alexreg @nikomatsakis @tmandry

[eddyb]

I wonder if the supertraits query is including the associated type bound - AFAIK it should only include the bounds specified on Self itself, not associated types of Self or other types.

[alexreg]

@eddyb I know that was a problem previously, though I introduced a filter in relevant places to combat it. We may need to introduce a filter in another place.

[jendrikw]

This issues still happens, are there any updates on fixes?

[compiler-errors]

As of #110512, this is no longer a cycle error, and the code above errors with:

error[E0277]: the trait bound `<<Self as A>::T as A>::T: B` is not satisfied
 --> /home/../test.rs:7:15
  |
7 | trait B: A<T: B> {}
  |               ^ the trait `B` is not implemented for `<<Self as A>::T as A>::T`
  |
note: required by a bound in `B`
 --> /home/../test.rs:7:15
  |
7 | trait B: A<T: B> {}
  |               ^ required by this bound in `B`
help: consider further restricting the associated type
  |
7 | trait B: A<T: B> where <<Self as A>::T as A>::T: B {}
  |                  +++++++++++++++++++++++++++++++++

The fact that this still errors is a somewhat unfortunate side-effect of #65913 (comment), since the <Self as A>::T: B bound is not implied by the supertrait bounds.

Fixing this in a way that doesn't cause the compiler to overflow generating an infinite nested set of <<<<<<... as A>::T as A>::T as A>::T as A>::T as A>::T as A>::T: B bounds is gonna be pretty difficult, though.

[fmease]

This now hangs on nightly (not only the sugared form but also the desugared one) with both the old and the new solver.

@rustbot label I-hang E-needs-bisection

[fmease]

Regressed in #112629 (git-revert: hang → errors). CC @compiler-errors
@rustbot label -E-needs-bisection

[compiler-errors]

I don't believe this will ever be made to compile. A cycle error IMO is the correct state for this. Diagnostics could perhaps be improved, but they would need to explain some details about how supertrait bound elaboration works.