Support trait objects in type info reflection #151239
Draft
+482
−2
Conversation
This file contains hidden or 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
rustbot
added
S-waiting-on-review
rustbot
added
the
T-libs
Collaborator
|
|
rustbot
added
S-waiting-on-author
Author
|
I don't mind if anyone forks the branch to implement the for<'a> part, or even make a separate PR for a better implementation |
SpriteOvO
reviewed
Jan 17, 2026
Comment on lines
219
to
233
| Type { | ||
| kind: DynTrait( | ||
| DynTrait { | ||
| super_traits: [ | ||
| TypeId(0xf726af39bcd0090512f636802780d009), | ||
| TypeId(0xd3eba1307d3a0b58acd77b80e4532fbf), | ||
| ], | ||
| is_auto: false, | ||
| auto_traits: [ | ||
| TypeId(0x0d5e48167084e668b711d10061f0446a), | ||
| ], | ||
| }, | ||
| ), | ||
| size: None, | ||
| } |
Member
There was a problem hiding this comment.
trait A {}
trait B: A {}
trait C: B {}The quoted dump is the type info for dyn C + Send. How do we determine whether it has trait C?
Author
There was a problem hiding this comment.
Sorry, I don't think I fully understand the question. Could you elaborate?
Member
There was a problem hiding this comment.
For clear, I replaced the type ID number with type name in the following examples.
First, TypeId(dyn C) != TypeId(dyn C + Send), then the type info of dyn C + Send is
Type {
kind: DynTrait(
DynTrait {
super_traits: [
TypeId(B),
TypeId(A),
],
is_auto: false,
auto_traits: [
TypeId(Send),
],
},
),
size: None,
}
For the current PR implementation, if given a dyn C + Send (or type ID of it), we can know there are A, B and Send but no way of knowing C.
Author
There was a problem hiding this comment.
I did not include C in it since C is not a super trait of itself. I am assuming you want a field that represents the TypeId of the trait object itself?
Member
There was a problem hiding this comment.
Not exactly, dyn C and dyn C + Send are two different things, so it's not "the trait object itself".
Intuitively, I think DynTrait's layout should probably look something like this. Take dyn C + Send as an example again.
Type {
kind: DynTrait(
DynTrait {
predicates: [ Predicate(Trait(C)), Predicate(Trait(Send)) ]
},
),
size: None,
}
Predicate {
trait,
negative: bool, // Not sure if possible, #144241
}
Trait(C) = Trait {
supers: [ Trait(B), Trait(A) ],
is_auto: false,
}
Trait(Send) = Trait {
supers: [],
is_auto: true,
}
Trait(B) = ...
Trait(A) = ...
Author
There was a problem hiding this comment.
This makes a lot of sense! I will go with this
Author
|
An ICE occurs when trying to get the type_info of a dyn trait, in which one of it's supertrait has for<'a> (eg |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Tracking issue: #146922
I can't seem to get it to work correctly with
dyn for<'a> Foo<'a>, though it works fine for normaldyn Footrait objectsr? @oli-obk