Uh oh!
There was an error while loading. Please reload this page.
Introduce SolverRelating type relation to the new solver code - #128744
Introduce SolverRelating type relation to the new solver code#128744compiler-errors wants to merge 3 commits into
SolverRelating type relation to the new solver code#128744Conversation
rustbot
commented
Aug 6, 2024
changes to the core type system |
This comment has been minimized.
This comment has been minimized.
d39fa4d to
162dfa0Comparelcnr
commented
Aug 7, 2024
generally in favor of splitting |
Uh oh!
There was an error while loading. Please reload this page.
lcnr
commented
Aug 14, 2024
we discussed that we'll have to add |
lcnr
commented
Aug 14, 2024
@rustbot author |
bors
commented
Aug 22, 2024
☔ The latest upstream changes (presumably #129365) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
commented
Oct 1, 2024
I'll need to totally rework this, so closing for now and putting it back onto my TODO list for a fresh PR, which will be soon hopefully. |
Introduce SolverRelating type relation to the new solver Redux of rust-lang#128744. Splits out relate for the new solver so that implementors don't need to implement it themselves. r? lcnr
This "uplifts" (i.e. duplicates) the
TypeRelatingdelegate into the new solver as a new relation calledSolverRelating, so we can use that rather than exposingInferCtxtLike::relatefor implementations to have to implement themselves.The reason I duplicated rather than fully uplifted
TypeRelatingis because it's so complicated.CombineFieldsis a bunch of unnecessary machinery that only exists to track aTraceand to make it easy to swap betweenLub/Glb.next_trait_solverbranches in in thesuper_combine_{const,ty}functions, and in theTypeRelatingcode itself that can be folded away.This then allows us to remove
StructurallyRelateAliasesfromPredicateEmittingRelationand move it directly onto the generalizerinstantiate_*_varfunctions.r? @lcnr -- I'm curious what you think of this approach in general.