One of the things that @pnkfelix and I were discussing -- basically, maybe it would make sense to build something more like rustc's engine, but operating on lowered chalk predicates? rustc's engine is quirky but of course it works "well enough" for rustc today, and it might make it easier to adopt chalk into rustc sooner rather than later.

Following up from that, I was pondering another possible design, one closer to the older 'recursive' solver that chalk used to have before the SLG solver. In short, it was always looking for a unique solution, unlike the existing chalk-engine solver that is based around finding exact solutions (and then having an outer layer that stops asking for more answers). I do remember we had some problems where the recursive solver wasn't strong enough to handle some cases, though I can't remember exactly what (@scalexm maybe remembers).

Anyway, I think that one of these two things might make sense as a way to get chalk integrated "sooner rather than later". But I think this is something to consider more as a second step, once we've integrated the chalk-solve crate into rustc.

(That could be done gradually, though)

i.e., we could gradually refactor rustc's enum until it basically matches the chalk enum

which would probably be good, since it might inform whether chalk's enum has the right set of variants (in particular, I think we might want to extract the integral / floating point types out, because of the way that rustc's integer literals work)