normalize in trait_ref_is_knowable in new solver#114457
normalize in trait_ref_is_knowable in new solver#114457bors merged 2 commits intorust-lang:masterfrom
trait_ref_is_knowable in new solver#114457Conversation
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
There was a problem hiding this comment.
Do you think lazy_normalize_ty should just return this FailureKind?
There was a problem hiding this comment.
hmm, I think it's valuable to guarantee that trait_ref_is_knowable always returns the outer Ok when used outside of the new solver
|
☔ The latest upstream changes (presumably #114492) made this pull request unmergeable. Please resolve the merge conflicts. |
d2d3fd4 to
ff150f9
Compare
|
@bors r=compiler-errors rollup |
This comment has been minimized.
This comment has been minimized.
|
@bors r- looks like we're hitting that stability assertion :( |
|
that sure is a nice way to get a minimized test ✨ |
|
lowered the stability check to a |
|
see rust-lang/trait-system-refactor-initiative#54 for an issue tracking the evaluate goal instability bug. @bors r=compiler-errors rollup (new solver) |
…ze, r=compiler-errors normalize in `trait_ref_is_knowable` in new solver fixes rust-lang/trait-system-refactor-initiative#51 Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into: - applicable without normalizing self type - applicable for aliases, even if they can be normalized - applicable for stuff which cannot get normalized further I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`. r? `@compiler-errors`
| Ok((has_changed, certainty, nested_goals)) | ||
| } | ||
|
|
||
| fn check_evaluate_goal_stable_result( |
There was a problem hiding this comment.
This check should even when debug assertions are enabled -- otherwise, there's UI test instability between rustc w/ debug_assertions and not.
|
Failed in rollup @bors r- |
bf154dc to
d502fff
Compare
|
rebased on top of #114694 so |
d502fff to
5176288
Compare
|
@bors r+ |
…ze, r=compiler-errors normalize in `trait_ref_is_knowable` in new solver fixes rust-lang/trait-system-refactor-initiative#51 Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into: - applicable without normalizing self type - applicable for aliases, even if they can be normalized - applicable for stuff which cannot get normalized further I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`. r? `@compiler-errors`
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (7455aa5): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 632.32s -> 633.837s (0.24%) |
fixes rust-lang/trait-system-refactor-initiative#51
Alternatively we could avoid normalizing the self type and do this at the end of the
assemble_candidates_via_self_tystack by splitting candidates into:I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in
trait_ref_is_knowable.r? @compiler-errors