-
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
Deal with unnormalized projections when structurally resolving types with new solver #110204
Deal with unnormalized projections when structurally resolving types with new solver #110204
Conversation
1d91b94
to
2e3766d
Compare
I'll re-roll the review dice 🎲 (hope it's fine since the autoassigned reviewer didnt yet comment) r? compiler |
@apiraino, this basically needs to be reviewed by lcnr r? lcnr |
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.
is the structurally_normalize
vs structurally_resolve
split meaningful, i.e. is there a case where we would want to have different behavior?
I could imagine having infcx.structurally_resolve(&mut fulfill_cx, span, ty)
which returns Err
if the ty
cannot be resolved to a rigid ty.
☔ The latest upstream changes (presumably #110806) made this pull request unmergeable. Please resolve the merge conflicts. |
@lcnr: Not sure if I understand the changes you're asking for. The distinction between The problem here is we are trying to unify two somewhat different codepaths -- one coming from |
2e3766d
to
9c65181
Compare
☔ The latest upstream changes (presumably #111570) made this pull request unmergeable. Please resolve the merge conflicts. |
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 dealing with comments. opened rust-lang/trait-system-refactor-initiative#14 and rust-lang/trait-system-refactor-initiative#15 so i don't forget about this
// This shouldn't happen, except for evaluate/fulfill mismatches, | ||
// but that's not a reason for an ICE (`predicate_may_hold` is conservative | ||
// by design). |
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.
when do we actually hit that path? do we have an existing test for it?
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.
No :( doesn't seem like anything hits it.
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.
I personally would prefer to ICE here to get a test 😁 but ah well, r=me with or without bug!
:p
9c65181
to
4cfafb2
Compare
@bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (4400d8f): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 644.072s -> 644.363s (0.05%) |
structurally_resolved_type
when the new solver is enabledAutoderef
when the new solver is enabledresolve_type
in writebackThis is motivated by the UI test provided, which currently fails with:
I'm pretty happy with the approach in (1.) and (2.) and think we'll inevitably need something like this in the long-term, but (3.) seems like a hack to me. It's a lot of work to add tons of new calls to every user of these typeck results though (mir build, late lints, etc). Happy to discuss further.
r? @lcnr