-
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
don't add implied bounds after normalization #99832
Conversation
this allows us to soundly use unnormalized projections for wf
The job Click to see the possible cause of the failure (guessed by this bot)
|
Is this only a problem in #99217, not on master? If so, this needs to be merged into that PR. I don't think we should not treat normalized types as implied, but rather I think we need to fully prove (including region obligations) that the projection ty normalizes. |
It's a problem on master, or well, I am not sure if it is a problem, because while surprising, i wasn't able to cause ub with it |
I agree this is not a soundness problem. Moreover I think with #99217 we can even ignore the region obligations generated by normalizing It was an experiment to resolve this surprising behavior, but I missed the case where the projection is normalized to a type parameter in |
Fix implied outlives bounds logic for projections The logic here is subtly wrong. I put a bit of an explanation in a767d7b5165cea8ee5cbe494a4a636c50ef67c9c. TL;DR: we register outlives predicates to be proved, because wf code normalizes projections (from the unnormalized types) to type variables. This causes us to register those as constraints instead of implied. This was "fine", because we later added that implied bound in the normalized type, and delayed registering constraints. When I went to cleanup `free_region_relations` to *not* delay adding constraints, this bug was uncovered. cc. `@aliemjay` because this caused your test failure in rust-lang#99832 (I only realized as I was writing this) r? `@nikomatsakis`
Forked from #99217 because it is a preexisting problem. cc @lcnr
We should not add implied bounds for the normalized type because we don't know for sure if the normalization holds.
Consider this example:
This now fails in stable as expected, but with this change it passes!
r? @ghost