Change:
<ins> // check-pass // edition:2018 #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] use std::future::Future; trait SearchableResource<Criteria> { type SearchResult; } trait SearchableResourceExt<Criteria>: SearchableResource<Criteria> { type Future<'f, A: 'f + ?Sized, B: 'f>: Future<Output = Result<Vec<A::SearchResult>, ()>> + 'f where A: SearchableResource<B>; fn search<'c>(&'c self, client: &'c ()) -> Self::Future<'c, Self, Criteria>; } type SearchFutureTy<'f, A, B: 'f> where A: SearchableResource<B> + ?Sized + 'f, = impl Future<Output = Result<Vec<A::SearchResult>, ()>> + 'f; impl<T, Criteria> SearchableResourceExt<Criteria> for T where T: SearchableResource<Criteria>, { type Future<'f, A, B: 'f> where A: SearchableResource<B> + ?Sized + 'f, = SearchFutureTy<'f, A, B>; fn search<'c>(&'c self, _client: &'c ()) -> Self::Future<'c, Self, Criteria> { async move { todo!() } } } fn main() {} </ins>

Discussion:
Using an associated type as an argument to a GAT will sometimes fail with an incorrect "trait bound is not satisfied" error, when that type is used to constrain an associated type of another trait. This code should compile fine. In particular, should be valid because is constrained to implement . However, the compilation fails with the following error: The trait bound is obviously satisfied, so something is wrong here. The suggested clause does not fix the error, instead the compiler will suggest you add another one. <details<summaryAdding the same bound again and again</summary<p</p</detailsThis error occurs even if the first two s, and , are part of other traits (implemented either by or some generic type arguments). The error seems to be affected by the presence and ordering of other items in the trait. This code happily compiles: But swapping the two items causes the above error: Make sure to write each test in a separate trait to avoid other items messing with your testing. I initially thought the example did not produce an error because I had put it into the same trait as other working examples. I found another issue, , that produces the same error message. However, I'm not sure if that is the same bug because I could not get to error in only the return type position. That issue's example also uses the TAIT feature (which I'm unfamiliar with) so I was unable to reduce it enough to see similarities to my example. : As well as rust playground label +T-compiler +F-genericassociatedtypes +A-Traits +requires-nightly
I just re-ran the playground example and noticed that the issue seems to have vanished. The playground is running and my local installation is this: I have no idea if this was an intentional fix or these issues just randomly vanished and the TAIT bug I linked still reproduces. I didn't find mentions of how to handle this case in any docs, so I will simply close this issue.
Isn't it worth keeping this issue open so we can add a proper test, so this bug doesn't regress?

I tried this code: I expected to see this happen: It compiles or gives me a detailed error. Instead, this happened: Compiler suggests to add an already existing trait bound. Adding it one more time leads to compiler suggesting adding it once more and so on. While the code example uses GAT and TAIT, I'm not entirely sure both of those features are required to reproduce the issue. label +T-compiler +F-typealiasimpltrait +F-genericassociated_types +A-traits +requires-nightly
This compiles fine on the latest nightly, perhaps related to .