Implement some candidates for the new solver (redux)#107004
Implement some candidates for the new solver (redux)#107004bors merged 7 commits intorust-lang:masterfrom
Conversation
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
|
This doesn't completely duplicate the logic in #106384, but I'm going to go a bit slower to avoid doing too much work and then having it accidentally obsoleted by refactors 😅 I am pretty happy with the structure of the new assembly, though. |
|
☔ The latest upstream changes (presumably #106998) made this pull request unmergeable. Please resolve the merge conflicts. |
lcnr
left a comment
There was a problem hiding this comment.
would it make sense to take the
probe {
instantiate_constituent_tys_for_X
evaluate_goal_for_constituent_tys_and_make_canonical_response
}pattern and make that a function taking a closure/function for instantiate_constituent_tys_for_X, removing the separate function for
evaluate_goal_for_constituent_tys_and_make_canonical_response?
I think it would also be nice to maybe move all impls of instantiate_constituent_tys_for_X into a submodule as their concrete impl is fairly unimportant when trying to understand the solver.
Apart from these nits r=me 👍
e776e88 to
53f15c5
Compare
53f15c5 to
f672436
Compare
| for assumption in | ||
| elaborate_predicates(tcx, bounds.iter().map(|bound| bound.with_self_ty(tcx, self_ty))) | ||
| { | ||
| match G::consider_assumption(self, goal, assumption.predicate) { | ||
| Ok(result) => { | ||
| candidates.push(Candidate { source: CandidateSource::BuiltinImpl, result }) | ||
| } | ||
| Err(NoSolution) => (), | ||
| } | ||
| } |
|
@bors r+ rollup |
…didates-2, r=lcnr Implement some candidates for the new solver (redux) Based on rust-lang#106718, so the diff is hard to read without it. See [here](rust-lang/rust@98700cf...compiler-errors:rust:new-solver-new-candidates-2) for an easier view until that one lands. Of note: * 44af916020fb43c12070125c45b6dee4ec303bbc fixes a bug where we need to make the query response *inside* of a probe, or else we make no inference progress (I think) * 50daad5acd2f163d03e7ffab942534f09bc36e2e implements `consider_assumption` for traits and predicates. I'm not sure if using `sup` here is necessary or if `eq` is fine. * We decided that all of the `instantiate_constituent_tys_for_*` functions are verbose but ok, since they need to be exhaustive and the logic between each of them is not similar enough, right? r? `@lcnr`
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#105796 (rustdoc: simplify JS search routine by not messing with lev distance) - rust-lang#106753 (Make sure that RPITITs are not considered suggestable) - rust-lang#106917 (Encode const mir for closures if they're const) - rust-lang#107004 (Implement some candidates for the new solver (redux)) - rust-lang#107023 (Stop using `BREAK` & `CONTINUE` in compiler) - rust-lang#107030 (Correct typo) - rust-lang#107042 (rustdoc: fix corner cases with "?" JS keyboard command) - rust-lang#107045 (rustdoc: remove redundant CSS rule `#settings .setting-line`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Based on #106718, so the diff is hard to read without it. See here for an easier view until that one lands.
Of note:
consider_assumptionfor traits and predicates. I'm not sure if usingsuphere is necessary or ifeqis fine.instantiate_constituent_tys_for_*functions are verbose but ok, since they need to be exhaustive and the logic between each of them is not similar enough, right?r? @lcnr