-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
TypeId implements_trait #151236
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
base: main
Are you sure you want to change the base?
TypeId implements_trait #151236
Conversation
|
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr The reflection data structures are tied exactly to the implementation cc @oli-obk Some changes occurred to the CTFE machinery |
|
r? @chenyukang rustbot has assigned @chenyukang. Use |
|
Also, because this pull request is pretty much just copying and pasting from |
This comment has been minimized.
This comment has been minimized.
Sure , This way it's easier to maintain. |
|
Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
f603826 to
2f97f63
Compare
This comment was marked as outdated.
This comment was marked as outdated.
2f97f63 to
da054c7
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as off-topic.
This comment was marked as off-topic.
| /// Checks if the type represented by the `TypeId` implements the trait. | ||
| /// It can only be called at compile time. | ||
| pub const fn implements_trait< | ||
| T: ptr::Pointee<Metadata = ptr::DynMetadata<T>> + ?Sized + 'static, | ||
| >( | ||
| self, | ||
| ) -> bool { | ||
| type_id_implements_trait(self, TypeId::of::<T>()) | ||
| } | ||
|
|
||
| /// Checks if the type represented by the `TypeId` implements the trait represented by the secondary `TypeId`. | ||
| /// Returns `None` if the `trait_represented_by_type_id` is not a trait represented by type id. | ||
| /// It can only be called at compile time. | ||
| pub const fn implements_trait_represented_by_type_id( | ||
| self, | ||
| trait_represented_by_type_id: Self, | ||
| ) -> Option<bool> { | ||
| if type_id_is_trait(trait_represented_by_type_id) { | ||
| Some(type_id_implements_trait(self, trait_represented_by_type_id)) | ||
| } else { | ||
| None | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically, type_info feature gate mainly introduces a struct Type, which contains all the type information reflected from a TypeId.
Regarding whether a struct implements a trait, I think this also relates to "reflection". Based on this, I would suggest that associating them with struct Type (becoming methods of it) might be more appropriate.
For naming, personally, has_trait feels more intuitive than implements_trait to me, though it's still too early to do name decisions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points. I agree that has_trait does make more sense, especially when considering that the trait might not be implemented by the type specifically, and rather have come from a blanket.
| /// Check if a type represented by a `TypeId` is a dyn Trait. | ||
| /// It can only be called at compile time, the backends do | ||
| /// not implement it. | ||
| #[rustc_intrinsic] | ||
| #[unstable(feature = "core_intrinsics", issue = "none")] | ||
| pub const fn type_id_is_trait(_trait: crate::any::TypeId) -> bool { | ||
| panic!("`TypeId::implements_trait_represented_by_type_id` can only be called at compile-time") | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This likely doesn't require a dedicated intrinsic. we can determine it through variants of enum TypeKind. Someone happens to be working on this, see #151239. Maybe you can wait for it to land.
| mod step; | ||
| mod traits; | ||
| mod util; | ||
| pub mod util; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked closely at how CompileTimeMachine interacts with InterpCx, but I believe there's a better way to share code than putting it into the util mod.
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
|
☔ The latest upstream changes (presumably #151363) made this pull request unmergeable. Please resolve the merge conflicts. |
This is for #146922.
It allows checking if a
TypeIdimplements a trait.(I've never used git from the terminal before, so that was a fun challenge. I hope I did everything correctly.)
(I haven't added any tests yet, I'll do that soon.)
(Zulip.)