-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Turn type_id
into a constant intrinsic
#47892
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
I basically copied @eddyb 's #42859, as it's my first time dealing with compiler instrinsics. In miri/const_eval.rs there's an error called "NeedsRfc", which would suggest that adding intrinsics to const_eval needs some discussion, so I'm not sure if my PR would be allowed. I added a few lines of code to an existing test because I don't know what exactly to test, so any suggestions welcome. As for the |
Do the type IDs change between compilations? According to the docs they'll change between releases and platforms. I guess this could be said of type_size, too, but that one is at least predictable in some manner. Should definitely be unstable const fn until it can actually be added to Any |
As I understand they're basically keys to a hashmap, right? So completely
unstable between compiler versions. Like enum discriminants but worse.
However, that's already the case with TypeId::of.
…On Wed, Jan 31, 2018 at 7:06 AM, Oliver Schneider ***@***.***> wrote:
Do the type IDs change between compilations?
According to the docs they'll change between releases and platforms. I
guess this could be said of type_size, too, but that one is at least
predictable in some manner.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#47892 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n9yn9Ua4qxNMpFhnbnGmm1cbuBPRks5tQALWgaJpZM4RzI_i>
.
|
`#[rustc_const_unstable(feature="const_type_id")]` is what @eddyb is asking
for.
…On Wed, Jan 31, 2018 at 7:14 AM, Alex Burka ***@***.***> wrote:
As I understand they're basically keys to a hashmap, right? So completely
unstable between compiler versions. Like enum discriminants but worse.
However, that's already the case with TypeId::of.
On Wed, Jan 31, 2018 at 7:06 AM, Oliver Schneider <
***@***.***> wrote:
> Do the type IDs change between compilations?
>
> According to the docs they'll change between releases and platforms. I
> guess this could be said of type_size, too, but that one is at least
> predictable in some manner.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#47892 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAC3n9yn9Ua4qxNMpFhnbnGmm1cbuBPRks5tQALWgaJpZM4RzI_i>
> .
>
|
With miri we could make sure that no decisions are made on that value. |
Uh... define "decisions"? That sounds like a potentially really annoying
restriction.
…On Jan 31, 2018 08:07, "Oliver Schneider" ***@***.***> wrote:
So completely unstable between compiler versions. Like enum discriminants
but worse.
With miri we could make sure that no decisions are made on that value.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#47892 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n_sP8od1eq9k7Xn1ldjMLrKI7Xe9ks5tQBEtgaJpZM4RzI_i>
.
|
You can't use it as an index to arrays, you can't compare it to anything but other values derived from |
I'd rather not go crazy about it - it's your fault if you misuse this random (but deterministic within one compilation) number that the compiler gave you. |
Thanks @durka, but it was really hard to find documentation about it. I assume that when you add it to a stable function, and that function is called in a non-const context, it works the same as before? Because |
@@ -91,4 +92,11 @@ pub fn main() { | |||
// Check fn pointer against collisions | |||
assert!(TypeId::of::<fn(fn(A) -> A) -> A>() != | |||
TypeId::of::<fn(fn() -> A, A) -> A>()); | |||
|
|||
// Check const | |||
const T1: TypeId = TypeId::of::<A>(); |
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 should be in a separate file to ensure that TypeId::of
without the feature enabled still works
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 agree, this test is only temporal as I didn't know what to test. (It still works btw).
2da171f
to
80cb8b3
Compare
✌️ @oli-obk can now approve this pull request |
ping @oli-obk |
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.
Just a style thing, Lgtm otherwise
|
||
fn main() { | ||
const A_ID: TypeId = TypeId::of::<A>(); | ||
//~^ ERROR `std::any::TypeId::of` is not yet stable as a const fn |
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.
Ah, this is a good test that I forgot about. What I meant was an extra file that uses TypeId::of
without the feature gate in a non const context.
....
And a quick search shows there are already files testing that. Don't mind me
src/librustc_trans/mir/constant.rs
Outdated
let llval = C_u64(self.cx, | ||
self.cx.tcx.type_id_hash(substs.type_at(0))); | ||
Ok(Const::new(llval, tcx.types.u64)) | ||
|
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.
Nit: remove this empty line
Add rustc_const_unstable attribute for `any::TypeId::of` Add test for `const fn TypeId::of`
80cb8b3
to
196fad0
Compare
@bors r=oli-obk |
📌 Commit 196fad0 has been approved by |
Turn `type_id` into a constant intrinsic rust-lang#27745 The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.
#27745
The method
get_type_id
inAny
is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes thetype_id
intrinsic a constant intrinsic, the same assize_of
andalign_of
, allowingTypeId::of
to be aconst fn
, which will allow using an associated constant inAny
.