Tracking issue for `const fn` `type_name`

[oli-obk]

This is a tracking issue for making and stabilizing type_name as const fn. It is not clear whether this is sound. Needs some T-lang discussion probably, too.

Steps needed:

• Implementation (essentially add const and #[rustc_const_unstable(feature = "const_type_name") to the function and add tests showing that it works at compile-time.
• fix type_name depends on -Zverbose flag #94187
• check if TypeId exposes equality-by-subtyping vs normal-form-syntactic-equality unsoundness. #97156 replicates for type_name, too
• Stabilization
  • Note that stabilization isn't happening any time soon. This function can change its output between rustc compilations and allows breaking referential transparency. Doing so at compile-time has not been discussed fully and has various points that are problematic.

[RalfJung]

This function can change its output between rustc compilations

Can the output change between compiling a library crate, and a binary crate using that library? Or only when switching rustc versions?

[oli-obk]

Can the output change between compiling a library crate, and a binary crate using that library?

No, we're using global paths now.

Or only when switching rustc versions?

Yes, there needs to be a change in rustc that causes a change in output.

[TankhouseAle]

I might take a look at this. (I implemented the support for using the actual type_name intrinsic in const fn contexts, if you don't remember me, haha.)

I think we definitely know it works at compile time though, don't we? That's what this test I added at the time checks for.

[TankhouseAle]

Sorry it took me a bit to get to this. Just opened a PR.