-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
TypeRelating
delegate into the new solver as a new relation calledSolverRelating
, so we can use that rather than exposingInferCtxtLike::relate
for implementations to have to implement themselves.The reason I duplicated rather than fully uplifted
TypeRelating
is because it's so complicated.CombineFields
is a bunch of unnecessary machinery that only exists to track aTrace
and to make it easy to swap betweenLub
/Glb
.next_trait_solver
branches in in thesuper_combine_{const,ty}
functions, and in theTypeRelating
code itself that can be folded away.This then allows us to remove
StructurallyRelateAliases
fromPredicateEmittingRelation
and move it directly onto the generalizerinstantiate_*_var
functions.r? @lcnr -- I'm curious what you think of this approach in general.