-
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
Prohibit unconstrained lifetimes that appear in associated types #24461
Prohibit unconstrained lifetimes that appear in associated types #24461
Conversation
@bors r=aturon p=1 8eb2b14 Giving p=1 because this is a soundness fix. |
📌 Commit b8282dd has been approved by |
⌛ Testing commit b8282dd with merge b9a83fc... |
💔 Test failed - auto-mac-64-opt |
b8282dd
to
d504d12
Compare
📌 Commit d504d12 has been approved by |
⌛ Testing commit d504d12 with merge 6a40cec... |
💔 Test failed - auto-mac-32-opt |
multiple kinds of parameters (regions and types, specifically)
which get mentioned in an associated type are constrained. Arguably we should just require that all regions are constrained, but that is more of a breaking change.
d504d12
to
5368070
Compare
⌛ Testing commit 5368070 with merge 4879b3b... |
💔 Test failed - auto-mac-64-nopt-t |
@bors retry // segfault is ... probably not our fault, I want to see how repeatable it is |
⌛ Testing commit 5368070 with merge b62cb9e... |
💔 Test failed - auto-mac-64-nopt-t |
@bors retry // acrichto claims this is fixed |
…turon This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime. r? @aturon Fixes #22077.
soundness fix. going from nominated to (nominated, accepted) |
This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime.
r? @aturon
Fixes #22077.