Florian Diebold
Florian Diebold
Yeah. It's actually surprising that this doesn't work though, since solutions do get combined using `combine`: https://github.com/rust-lang/chalk/blob/10ba203d660ac1ee80f19b5d162ae6e62f6b9ee1/chalk-solve/src/solve.rs#L64-L89 and if the solution doesn't have variables and is unique, the `self ==...
I think the original case is actually the same problem as I investigated in #750. @matthewjasper's `impl_that_should_work2` is also interesting in that it's also a case where the recursive solver...
Looking into https://github.com/rust-lang/chalk/issues/727, it does at least seem to be caused by the same implied env rule.
> The only other thought I have is how useful it is to validate all bound vars in a "type" (or whatever we're checking), versus just checking for bound vars...
I think the difference that's likely the source of problems is that rust-analyzer (and I think I got this from rustc) puts the closure signature in a function pointer type...
It's also worth noting that rust-analyzer never passes any lifetimes except `'static` to Chalk.
Rust-analyzer doesn't do any WF checking either though, so we can probably get away with a stub implementation of these callbacks.
Yes, I've had similar problems reproducing problems with closures from RA. Maybe the closure support in the test harness needs to be more flexible somehow. I've usually been able to...
> The thought I think initially was that getting back ambiguity here was ok, and that normally you'd get forced down path or the other from the top-level, but it'd...
Ok, I moved the first one to a separate issue.