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.
build something more like rustc's engine, but operating on lowered chalk predicates?
Can we refactor existing solver from within such that it operates on the said input format?
(existing rustc solver that is)
This has a benefit of having only two parallel solvers, and not three, at any given point in time)
I wondered about that path
I think it's roughly equivalent
That is, I think the goal would be to build up the solver in chalk and then asap remove the one from rustc
Well I guess the question is can we do it gradually within rustc
I don't see how, but maybe
Really the most important thing here -- probably -- is to figure out the caching questions for 'lowering'
Also, a related question:
I've been describing a design that merges chalk types with rust types by having two parallel definitions that will eventually merge
But this could be a performance hazard, and I guess the goal should probably be to merge the type definitions sooner rather than later
Probably "just" rote work within 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)