Support primitives in type info reflection

[SpriteOvO]

Tracking issue: #146922 #![feature(type_info)]

This PR supports {bool,char,int,uint,float,str} primitive types for feature type_info reflection.

r? @oli-obk

[rustbot]

The reflection data structures are tied exactly to the implementation
in the compiler. Make sure to also adjust rustc_const_eval/src/const_eval/type_info.rs

cc @oli-obk

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[SpriteOvO]

I also added a ty: TypeId to all primitive variants to represent their own type. The rationale is that users won't need to manually retrieve the TypeId when accessing type info (especially through Type::of::<T>() usage). I'm not sure if this approach is advisable, and whether it's necessary to also provide a ty: TypeId for other variants like Tuple and Array.

View changes since this review

[SpriteOvO]

I'm not sure whether we should use usize or u64 here to represent the bit width.

Besides, as Option is not used here, reflection on isize and usize will fall into the Int and Uint variants, and users cannot distinguish between them, which may be an issue.

Is it necessary for end users to distinguish between {u,i}size and {u,i}int? If yes, should we add a separate field or add distinct variants to indicate it?

[oli-obk]

I think having a single Int variant that has a signed: bool field is nicer. It avoids some recurring matches that do Int(_) | Uint(_)

[SpriteOvO]

I also added a ty: TypeId to all primitive variants to represent their own type. The rationale is that users won't need to manually retrieve the TypeId when accessing type info (especially through Type::of::<T>() usage). I'm not sure if this approach is advisable, and whether it's necessary to also provide a ty: TypeId for other variants like Tuple and Array.

In that case, it might be better to place ty: TypeId under struct Type rather than under enum TypeKind's variants I think.

[oli-obk]

Yea I think we can leave off the extra TypeId field. I understand that reflection libraries have that on their Opaque variant, but they can still do that when processing the rustc reflection info. I'd rather users invoke TypeId::of manually when they also need the type id

View changes since this review

[oli-obk]

I think having a single Int variant that has a signed: bool field is nicer. It avoids some recurring matches that do Int(_) | Uint(_)

[oli-obk]

ohh great idea, thanks!