-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 selection via new trait solver #112869
Conversation
☔ The latest upstream changes (presumably #112938) made this pull request unmergeable. Please resolve the merge conflicts. |
412c831
to
deadc39
Compare
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.
r=me after nits and updating description
deadc39
to
2c4b85d
Compare
This comment has been minimized.
This comment has been minimized.
2c4b85d
to
4905bc8
Compare
Are we intending on having a flag for only enabling the new solver for selection? |
No, the intention is just for this PR (and the deep normalization PR that lcnr has open) to remove the remaining entrypoints into old solver code when the new solver is enabled, since right now we still call into old solver logic during codegen and manual calls to Footnotes |
So this select stuff ideally only exists for codegen to figure out impls? |
Yes, that's the primary usecase, but we also use selection during the method probe and coercion logic I linked in the footnotes in my comment above (edited to include those). (Also in other things like const checking, but that's broken in the new solver anyways so shrug) |
implement deep normalization via the new solver together with rust-lang#112869 this should remove all uses of the old solver with `-Ztrait-solver=next`. see https://hackmd.io/V0qsUB_fTxexfQO_pcOcrg for a description of this PR. Will move that doc to the `rustc-dev-guide` after merging this. r? `@compiler-errors`
4905bc8
to
4bb5a25
Compare
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
This comment has been minimized.
This comment has been minimized.
4bb5a25
to
f3f8793
Compare
@bors r+ rollup (affects only new solver) |
…llaumeGomez Rollup of 3 pull requests Successful merges: - rust-lang#112869 (Implement selection via new trait solver) - rust-lang#113285 ([rustdoc] Fix display of long inline cfg labels) - rust-lang#113286 (Don't perform selection if inherent associated types are not enabled) r? `@ghost` `@rustbot` modify labels: rollup
Implements selection via the new solver by calling into
assemble_and_evaluate_candidates
, doing a very light-weight "winnow" to choose one candidate over the others, and then re-confirming that candidate outside of theEvalCtxt
in order to compute the information necessary for theImplSource
.This selection routine is best effort -- if it receives an ambiguous response from the
EvalCtxt
, then it may return ambiguity if the work to re-confirm the goal is not "easy" -- right now, that means everything except for object and impl goals. Since we don't want to reimplement all of the work of thecompute_builtin_*
methods in the solver internals, we bail out if we encounter ambiguity more often than the old solver. This should only barely affect method selection and not codegen. It can be made more precise later if needed.r? @lcnr