Repository navigation
Conversation
|
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred to the CTFE machinery The reflection data structures are tied exactly to the implementation cc @oli-obk Some changes occurred in compiler/rustc_attr_ir cc @jdonszelmann, @JonathanBrouwer Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
This PR contains some commits that are currently in a rollup. I'll rebase it once that merges. |
|
r? oli-obk |
This comment has been minimized.
This comment has been minimized.
e285bfa to
9cc6dd5
Compare
| /// | ||
| /// See [`TypeId::variant_getter`] on how to safely use this function. | ||
| #[lang = "variant_getter"] | ||
| unsafe fn variant_getter<T: 'static>(val: *const ()) -> VariantId { |
There was a problem hiding this comment.
why is the 'static bound needed here? We're in reflection territory, so if it's just for TypeId::of, you can also just use type_info::of::<T>()
| #[unstable(feature = "type_info", issue = "146922")] | ||
| #[rustc_const_unstable(feature = "type_info", issue = "146922")] | ||
| #[rustc_comptime] | ||
| pub fn variant_getter(self) -> fn(*const ()) -> VariantId { |
There was a problem hiding this comment.
you'll need to make the function pointer an unsafe function pointer, otherwise we have a safe function returning a safe function pointer that when called wrongly can cause UB
There was a problem hiding this comment.
can additionally recommend callers to debug assert the VariantId they are getting back for having a TypeId of the type they expected.
| pub fn type_id_variant_getter(_type_id: crate::any::TypeId) -> fn(*const ()) -> VariantId; | ||
|
|
||
| /// Returns a lookup table for converting between VariantId and Discriminant. This | ||
| /// is use internally by variant getter. **Please do not use this.** |
There was a problem hiding this comment.
by variant_getter (backticks and underscore)
| #[rustc_intrinsic] | ||
| #[unstable(feature = "core_intrinsics", issue = "none")] | ||
| #[rustc_comptime] | ||
| pub fn type_id_variant_getter(_type_id: crate::any::TypeId) -> fn(*const ()) -> VariantId; |
There was a problem hiding this comment.
same as TypeId::variant_getter: return fn ptr should be unsafe
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
9cc6dd5 to
c414965
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot)Important For more information how to resolve CI failures of this job, visit this link. |
We did not yet have a way to use reflection data for enum's at runtime. This adds a method to query the current
VariantIdgive no type information except theTypeId. We do this in two steps:To do 1) we need to generate code for the specific type. Specifically we need to generate
std::mem::discriminant. Emitting a function ptr during const-eval is enough to get a monomorphized version of that generated. To get 2) we have an intrinsic that returns a list ofVariantIdtoDiscriminantmapping. Getting the discriminant then looking it up in the mapping is packaged into a single function which is what the user actually calls.Since we have a lot of enum usage in rust the performance of this matters a lot. The current approach is suboptimal, the mapping is done through a linear scan and may not optimize out nicely. I suggest we put some effort in optimizing this after we are sure this will be the API.