Skip to content
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

Merged
merged 19 commits into from
Dec 27, 2018
Merged

Implement the new-style trait solver #56384

merged 19 commits into from
Dec 27, 2018

Conversation

scalexm
Copy link
Member

@scalexm scalexm commented Nov 30, 2018

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 for free.

r? @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 30, 2018
@rust-highfive

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Nov 30, 2018

☔ The latest upstream changes (presumably #56381) made this pull request unmergeable. Please resolve the merge conflicts.

@mark-i-m
Copy link
Member

mark-i-m commented Dec 1, 2018

The title of this PR is so epic

@bors
Copy link
Contributor

bors commented Dec 8, 2018

☔ The latest upstream changes (presumably #56578) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@nikomatsakis nikomatsakis left a 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, &[]);
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

@scalexm scalexm Dec 17, 2018

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.

src/librustc_traits/chalk_context/mod.rs Show resolved Hide resolved
src/librustc_traits/chalk_context/mod.rs Outdated Show resolved Hide resolved
src/librustc_traits/chalk_context/mod.rs Show resolved Hide resolved
src/test/ui/chalkify/type_inference.rs Show resolved Hide resolved
// `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>()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat.

@nikomatsakis nikomatsakis added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 19, 2018
@nikomatsakis
Copy link
Contributor

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.

@rust-highfive

This comment has been minimized.

@nikomatsakis
Copy link
Contributor

@bors r+

I think it's a good idea to land this so we can iterate in tree

@bors
Copy link
Contributor

bors commented Dec 27, 2018

📌 Commit 9dab10dcb7a506351ea81af9751a40dac63309ae has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 27, 2018
@bors
Copy link
Contributor

bors commented Dec 27, 2018

🔒 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 self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout chalk (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self chalk --force-with-lease (update this PR)

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 git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/test/ui/issues/issue-44415.stderr
Auto-merging src/test/ui/consts/const-size_of-cycle.stderr
Auto-merging src/librustc_typeck/check/compare_method.rs
Auto-merging src/librustc_traits/type_op.rs
Auto-merging src/librustc_traits/lowering/mod.rs
Auto-merging src/librustc_traits/lowering/environment.rs
Auto-merging src/librustc_traits/lib.rs
Auto-merging src/librustc_traits/dropck_outlives.rs
Auto-merging src/librustc_traits/chalk_context/program_clauses.rs
Auto-merging src/librustc_traits/chalk_context/mod.rs
Auto-merging src/librustc/ty/structural_impls.rs
Auto-merging src/librustc/ty/query/plumbing.rs
Auto-merging src/librustc/ty/query/mod.rs
Auto-merging src/librustc/ty/query/config.rs
Auto-merging src/librustc/ty/mod.rs
Auto-merging src/librustc/ty/fold.rs
Auto-merging src/librustc/ty/context.rs
Auto-merging src/librustc/traits/structural_impls.rs
Auto-merging src/librustc/traits/select.rs
Auto-merging src/librustc/traits/mod.rs
Auto-merging src/librustc/traits/fulfill.rs
Auto-merging src/librustc/traits/error_reporting.rs
Auto-merging src/librustc/traits/engine.rs
Auto-merging src/librustc/traits/auto_trait.rs
Auto-merging src/librustc/infer/mod.rs
Auto-merging src/librustc/infer/canonical/query_response.rs
Auto-merging src/librustc/infer/canonical/mod.rs
Auto-merging src/librustc/infer/canonical/canonicalizer.rs
Auto-merging src/librustc/ich/impls_ty.rs
Auto-merging src/librustc/dep_graph/dep_node.rs
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 27, 2018
@scalexm
Copy link
Member Author

scalexm commented Dec 27, 2018

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Dec 27, 2018

📌 Commit 993d213 has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 27, 2018
@bors
Copy link
Contributor

bors commented Dec 27, 2018

⌛ Testing commit 993d213 with merge fb86d60...

bors added a commit that referenced this pull request Dec 27, 2018
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
@bors
Copy link
Contributor

bors commented Dec 27, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing fb86d60 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants