-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add projection obligations when comparing impl too #115039
Add projection obligations when comparing impl too #115039
Conversation
r? @davidtwco (rustbot has picked a reviewer for you, use r? to override) |
Ideally I would prefer to use the unnormalized obligations but unfortunately there is #109628, which allows normalized obligations to have more implied bounds than the unnormalized ones. |
bors failed to recognize command? |
I think this just missed the version bump, so going to preemptively nominate for beta backport. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (fe5f591): 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)This benchmark run did not return any relevant results for this metric. 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: 636.268s -> 633.645s (-0.41%) |
Fixes #115051 |
[beta] backport and stage0 bump - Bump to released stable compiler - Add projection obligations when comparing impl too rust-lang#115039 r? cuviper
Fixes #115033
In the test, when we ask for WF obligations of
DatasetIter<'a, ArrayBase<D>>
, we get back two important obligations:[<D as Data>::Elem -> ?1, ?1: 'a]
. If we don't add the projection obligation,?1
remains unconstrained.An alternative solution would be to use unnormalized obligations, where we only have one relevant obligation:
<D as Data>::Elem: 'a
. This would leave no inference vars unconstrained.