-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Don't try to label ObligationCauseCode::CompareImplItem
for an RPITIT, since it has no name
#127404
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
Don't try to label ObligationCauseCode::CompareImplItem
for an RPITIT, since it has no name
#127404
Conversation
This comment has been minimized.
This comment has been minimized.
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.
Congradulences, you fixed an ICE 😆
r=me with crash test removed
yeah im just gonna delete the test since it's not particularly interesting |
…, since it has no name
9cf41da
to
d6276b3
Compare
@bors r=oli-obk rollup |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9e27377): comparison URL. Overall result: ❌✅ regressions and improvements - 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)Results (secondary -1.2%)This 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.
CyclesResults (secondary -0.5%)This 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: 699.359s -> 699.372s (0.00%) |
The old (current) trait solver has a limitation that when a where clause in param-env must be normalized using the same where clause, then we get spurious errors in
normalize_param_env_or_error
. I don't think there's an issue tracking it, but it's the root cause for many of the "fixed-by-next-solver" labeled issues.Specifically, these errors may occur when checking predicate entailment of the GAT that comes out of desugaring RPITITs. Since we use
ObligationCauseCode::CompareImplItem
for these predicates, we try callingitem_name
on an RPITIT which fails, since the RPITIT has no name.We simply suppress this logic when we're reporting a predicate entailment error for an RPITIT. RPITITs should never have predicate entailment errors, by construction, but they may due to this bug in the old solver.
Addresses the ICE in #127331, though doesn't fix the underlying issue (which is fundamental to the old solver).
r? types