-
Notifications
You must be signed in to change notification settings - Fork 14k
Introduce SolverRelating type relation to the new solver code
#128744
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
changes to the core type system |
This comment has been minimized.
This comment has been minimized.
d39fa4d to
162dfa0
Compare
|
generally in favor of splitting |
|
we discussed that we'll have to add |
|
@rustbot author |
|
☔ The latest upstream changes (presumably #129365) made this pull request unmergeable. Please resolve the merge conflicts. |
|
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.