Change:
fn main() { foo::<Vec<u32>>(vec![]); } <ins> mod another { use std::ops::Deref; fn test<T, TDeref>() where T: Deref<Target = TDeref>, TDeref: ?Sized, for<'a> &'a TDeref: IntoIterator, for<'a> <&'a TDeref as IntoIterator>::IntoIter: Clone, { } fn main() { test::<Vec<u8>, _>(); } } </ins>

Discussion:
I tried this code: () I expected to see this happen: the code compiles fine. Instead, this happened: and fails to type check, and although the error message is not related to type inference, annotating the type parameter fixes the problem. the same thing happens when removing the bound , but then for all . Seems to be related to . cc <details<summaryError message</summary<p</p</details Tested on nightly branches of playground: Nightly version: 1.58.0-nightly (2021-11-09 )
label T-compiler, A-typesystem, A-lifetimes, A-inference, A-closures, A-traits
Prior to v1.56, closures and functions all fail alike with the same error message and adding type annotations didn't help either. So my guess is that (edit: and ) introduced an (incomplete?) fix, so I think this now needs to: address the inconsistency improve error message to require type annotations label A-diagnostics
While changing the error message could improve the situation, this is clearly not exclusively a diagnostics issue, AFAICT. To avoid potential confusion, let me remove the A-diagnostics label, which is commonly applied to issues that are purely diagnostics issues. label -A-diagnostics. In case it is decided that this is only a diagnostics issue after all, the label can be reapplied. In case the inconsistency is somehow fixed and diagnostics issues remain, a new A-diagnostics issue can be opened.
I've just been aware of the version differences and recent efforts to solve this. So here is a summary: Prior to 1.56, all cases failed even with type annotations. On 1.56 (due to ??), all cases still fail but type annotation workaround now works. On nightly (due to ??), closures (rather than functions) no longer require type annotation. A duplicate of .
closed as a dupe, there are additional testcases in that issue that should probably be checked when fixing this.

I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind: