Optionally add type names to TypeIds.

[kpreid]

This feature is intended to provide expensive but thorough help for developers who have an unexpected TypeId value and need to determine what type it actually is. It causes impl Debug for TypeId to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to TypeId. The cost of this is the increased size of TypeId and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the Debug implementation.

It may be enabled via cargo -Zbuild-std -Zbuild-std-features=debug_typeid. (Note that -Zbuild-std-features disables default features which you may wish to reenable in addition; see
https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features.)

Example usage and output:

fn main() {
    use std::any::{Any, TypeId};
    dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}

TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)

Also added feature declarations for the existing debug_refcell feature so it is usable from the rust.std-features option of config.toml.

Related issues:

• Expose type_name() method on Any. #68379
• Intrinsic for type_name_of_id to power a better impl Debug for TypeId? #61533

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Question: not a libs reviewer, but, is this¹ documented anywhere? Feels like only 3 people will ever know if these features exists otherwise lol.

Footnotes

1. or rather, I guess the core/std options in general. ↩

I entirely agree that that’s a problem, and I’m not aware of any documentation for std features. I expect the main way people will discover this feature is by looking at the source code of TypeId (which is linked from rustdocs, so is trivial to find).

On the other hand, maybe there is documentation for std features, in which case this PR certainly should add to it.

Maybe std-dev-guide but I think that's a submodule of a repo somewhere else.

Yeah, better documentation would be nice. But as it's missing for the other features as well, I don't think this should be done in this PR.

Sound good too me. The implementation looks fine to me, let me just ask T-libs for confirmation.

r=me if T-libs is fine with adding this feature

IMO, this sort of quality of life improvement is not worth the extra cargo-based feature and -Zbuild-std dependency. It makes it more painful to evolve TypeId and seems easy to land a proliferation of this sort of tweak to how std/core work in a way that's hard for us to maintain long term.

It seems plausible that we could have a table of TypeIds emitted somewhere by rustc that let's you do this lookup offline though.

I see your point about complexity of miscellaneous features, but regarding the specific alternative, wouldn’t a rustc feature to do that likely be even more complex? I’ve frequently heard people wishing to have such a mapping, but the nice thing about doing it this way is that no management of the mapping is required, and the lookup is completely automatic and implicit. I get rejecting this change on grounds of clutter for maintainability — if nothing else, it’s easy enough to patch into a local copy — but it seems unwise to do so with the premise that rustc can do it better. I don’t expect it can.

rustc features have pretty clear costs too, but they're at least on a clear interface footing (available as -Z flag or similar). Expanding the build configurations of core via cfg is much less clear in terms of either stabilization path or easy-ish availability on nightly. It's also generally harder to ensure test quality (since you need to rebuild core etc, afaik we don't run any tests outside of the default config. Only that things build).

I think it would be better to duplicate the complete write! rather than breaking it up, so we avoid any impact to the normal feature-disabled case.

Done. I was thinking that there was no difference because it doesn't change the number of text fragments involved, but it does affect the number of write_fmt() calls, which might matter to something.

We discussed this in the libs meeting last week and were happy to have this as an unstable feature.

Alright, let's ship this!
@bors r+

📌 Commit d2ed8cf has been approved by joboet

It is now in the queue for this repository.

The coretests crate doesn't have this feature, so this test will never actually run.

@kpreid

Opened #140155 to remove it.

Sorry for not getting back to this sooner — to give some context, this PR was probably originally written before the coretests split occurred (#135937), so the error was introduced by rebasing.