-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Implement the new-style trait solver #56384
Conversation
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #56381) made this pull request unmergeable. Please resolve the merge conflicts. |
The title of this PR is so epic |
☔ The latest upstream changes (presumably #56578) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for being so slow @scalexm -- this looks great, but I do have a few concerns:
- We should decide how to handle subtyping before landing; a FIXME may suffice here
- I'm a bit concerned about adding the def-id to param-env, it seems like this could affect queries in unintended ways, leading to less re-use than we would otherwise get
(Maybe we can only set the def-id if -Zchalk
is used for now?)
ty::Infer(..) => { | ||
// Everybody can find at least two types to unify against: | ||
// general ty vars, int vars and float vars. | ||
push_builtin_impl(tcx.types.i32, &[]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this worries me. I feel like there could be cases where chalk is able to try out all 4 of those possibilities and conclude that something is true since because it doesn't know of the other Sized
impls. But I see the challenge here, of course, in that to generate the "full set of sized impls" would in some sense require iterating over all the types in the system.
(This problem, though, doesn't seem entirely unique to sized
)
I wonder if we should think about tweaking how the engine walks around this case. It's probably ok to land the code as is for now, but we likely want to add some sort of FIXME issue here to revisit this question specifically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a hack indeed. We need to add a FIXME yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I believe this problem is indeed not unique to Sized
, but at least it would only show for traits that have built-in impls generated by the compiler. Other traits would be fine since we would be able to enumerate all the (user-written) impls.
// `Set<T>` is an input type of `take_a_set`, hence we know that | ||
// `T` must implement `Hash`, and we know in turn that `T` must | ||
// implement `Eq`. | ||
only_eq::<T>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat.
Current status to my knowledge: Waiting on @scalexm to rebase over the new version of chalk, at least, and perhaps to answer a few more of the questions above. |
This comment has been minimized.
This comment has been minimized.
@bors r+ I think it's a good idea to land this so we can iterate in tree |
📌 Commit 9dab10dcb7a506351ea81af9751a40dac63309ae has been approved by |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
The sub-visits were incorrectly combined with an `&&` instead of an `||`.
Multiple references to the same `BoundTy` were not using the same result.
@bors r=nikomatsakis |
📌 Commit 993d213 has been approved by |
Implement the new-style trait solver Final PR of what I believe to be a minimally working implementation of the new-style trait solver. The new trait solver can be used by providing the `-Z chalk` command line flag. It is currently used everywhere in `rustc_typeck`, and for everything relying on `rustc::infer::canonical::query_response::enter_canonical_trait_query`. The trait solver is invoked in rustc by using the `evaluate_goal` canonical query. This is not optimal because each call to `evaluate_goal` creates a new `chalk_engine::Forest`, hence rustc cannot use answers to intermediate goals produced by the root goal. We'll need to change that but I guess that's ok for now. Some next steps, I think, are: * handle region constraints: region constraints are computed but are completely ignored for now, I think we may need additional support from `chalk_engine` (as a side effect, types or trait references with outlive requirements cannot be proved well-formed) * deactivate eager normalization in the presence of `-Z chalk` in order to leverage the lazy normalization strategy of the new-style trait solver * add the remaining built-in impls (only `Sized` is supported currently) * transition the compiler to using generic goals instead of predicates that still refer to named type parameters etc I added a few very simple tests to check that the new solver has the right behavior, they won't be needed anymore once it is mature enough. Additionally it shows off that we get [implied bounds](#44491) for free. r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
Final PR of what I believe to be a minimally working implementation of the new-style trait solver.
The new trait solver can be used by providing the
-Z chalk
command line flag. It is currently used everywhere inrustc_typeck
, and for everything relying onrustc::infer::canonical::query_response::enter_canonical_trait_query
.The trait solver is invoked in rustc by using the
evaluate_goal
canonical query. This is not optimal because each call toevaluate_goal
creates a newchalk_engine::Forest
, hence rustc cannot use answers to intermediate goals produced by the root goal. We'll need to change that but I guess that's ok for now.Some next steps, I think, are:
chalk_engine
(as a side effect, types or trait references with outlive requirements cannot be proved well-formed)-Z chalk
in order to leverage the lazy normalization strategy of the new-style trait solverSized
is supported currently)I added a few very simple tests to check that the new solver has the right behavior, they won't be needed anymore once it is mature enough. Additionally it shows off that we get implied bounds for free.
r? @nikomatsakis