-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
ignore implied bounds with placeholders #112422
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
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 nits
// Because of #109628, we may have unexpected placeholders. Ignore them! | ||
// FIXME(#109628): panic in this case once the issue is fixed. | ||
let bounds = bounds.into_iter().filter(|bound| !bound.has_placeholders()); |
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.
can you move that into the TypeOp
?
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.
Moving this into the TypeOp has no benefit as we would have to duplicate the logic in QueryTypeOp::{perform_query,perform_locally_in_new_solver}
as well. It is also more difficult to handle canonicalized query responses - there is no easy way to detect placeholders for example.
Doing it in the query itself is difficult as we need to do OpportunisticRegionResolution
before checking for placeholders. Using TypeVisitableExt::has_placeholders
to check for erroneus placeholders there does not play well with #109388 as it would yield many false positives.
@aliemjay any updates on this? thanks |
☔ The latest upstream changes (presumably #117228) made this pull request unmergeable. Please resolve the merge conflicts. |
I think I have a case similar to #112250 in code at https://gitlab.com/chrysn/coap-message-demos branch embedded-nal-coap-clientserver when run as |
02f72b3
to
af79fd1
Compare
@rustbot review |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (4d7f952): comparison URL. Overall result: ✅ 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)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.
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: 676.982s -> 676.352s (-0.09%) |
( |
given the following code:
when computing the implied bounds from
Foo<X>
we incorrectly get the boundX: !x
from the normalization offor<'x> <X as Trait>::Ty::<'x>: Sized
. This is a a known bug! we shouldn't use the constraints that arise from normalization as implied bounds. See #109628.Ignore these bounds for now. This should prevent later ICEs.
Fixes #112250
Fixes #107409