-
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
normalize in trait_ref_is_knowable
in new solver
#114457
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
#[derive(Debug)] | ||
enum FailureKind { | ||
Overflow, | ||
NoSolution(NoSolution), | ||
} |
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.
Do you think lazy_normalize_ty
should just return this FailureKind
?
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, I think it's valuable to guarantee that trait_ref_is_knowable
always returns the outer Ok
when used outside of the new solver
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 nit or not
☔ 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_ty
stack 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