Search for implemented kinds recursively on Trait types. Fixes #15155 and #13155. #19011
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
|
Oh wow, I've always wanted this bug fixed, thanks @ricky26! r? @nikomatsakis |
|
Hi! Thanks for submitting this PR. As I wrote here, I think this is the right general idea, but you can just re-use the |
|
Ping @ricky26 |
|
@cmr I ended up being busy this week - I was going to fix this up today. |
|
No problem! Just checking if this PR is stalled :) |
ricky26
force-pushed
the
trait_supertraits
branch
from
dfd05ed to
729bf44
Compare
|
Okay @nikomatsakis, I've rebased and swapped the supertraits iteration code with a call to the utils::supertraits() method - I've had to create a temporary TraitRef though, since otherwise supertraits() panics. |
bors
added a commit
that referenced
this pull request
Nov 25, 2014
It looks like currently kinds required by traits are not propagated when they are wrapped in a TyTrait. Additionally, in SelectionContext::builtin_bound, no attempt is made to check whether the target trait or its supertraits require the kind specified. This PR alters SelectionContext::builtin_bound to examine all supertraits in the target trait's bounds recursively for required kinds. Alternatively, the kinds could be added to the TyTrait upon creation (by just setting its builtin_bounds to the union of the bounds requested in this instance and the bounds required by the trait), this option may have less overhead during compilation but information is lost about which kinds were explicitly requested for this instance (vs those specified by traits/supertraits) would be lost.
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.
It looks like currently kinds required by traits are not propagated when they are wrapped in a TyTrait. Additionally, in SelectionContext::builtin_bound, no attempt is made to check whether the target trait or its supertraits require the kind specified.
This PR alters SelectionContext::builtin_bound to examine all supertraits in the target trait's bounds recursively for required kinds.
Alternatively, the kinds could be added to the TyTrait upon creation (by just setting its builtin_bounds to the union of the bounds requested in this instance and the bounds required by the trait), this option may have less overhead during compilation but information is lost about which kinds were explicitly requested for this instance (vs those specified by traits/supertraits) would be lost.