Prohibit unconstrained lifetimes that appear in associated types #24461
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@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 |
nikomatsakis
force-pushed
the
issue-22077-unused-lifetimes
branch
from
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.
nikomatsakis
force-pushed
the
issue-22077-unused-lifetimes
branch
from
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 |
bors
added a commit
that referenced
this pull request
Apr 17, 2015
…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.
alexcrichton
added
the
beta-nominated
|
soundness fix. going from nominated to (nominated, accepted) |
pnkfelix
added
the
beta-accepted
alexcrichton
removed
the
beta-nominated
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.