Optionally add type names to `TypeId`s. #136148

kpreid · 2025-01-27T18:11:43Z

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:

rustbot · 2025-01-27T18:11:51Z

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

jieyouxu · 2025-01-28T05:09:14Z

library/core/Cargo.toml

+# Make `TypeId` store a reference to the name of the type, so that it can print that name.
+debug_typeid = []


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

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.

joboet

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

Mark-Simulacrum · 2025-01-29T14:03:57Z

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.

kpreid · 2025-01-29T17:44:13Z

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.

Mark-Simulacrum · 2025-01-29T18:11:07Z

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).

cuviper · 2025-02-05T17:36:30Z

library/core/src/any.rs

+        {
+            write!(f, " = {}", self.name)?;
+        }
+        write!(f, ")")


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.

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 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`.

m-ou-se · 2025-02-12T17:29:38Z

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

joboet · 2025-02-20T14:35:31Z

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

bors · 2025-02-20T14:35:34Z

📌 Commit d2ed8cf has been approved by joboet

It is now in the queue for this repository.

bjorn3 · 2025-04-01T15:17:04Z

library/coretests/tests/any.rs

    is_any::<[i32]>();
 }

+#[cfg(feature = "debug_typeid")]


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

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.

rustbot assigned joboet Jan 27, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 27, 2025

kpreid force-pushed the type-str branch from 9a6fa11 to d59c0a2 Compare January 27, 2025 18:26

jieyouxu reviewed Jan 28, 2025

View reviewed changes

joboet approved these changes Jan 29, 2025

View reviewed changes

cuviper reviewed Feb 5, 2025

View reviewed changes

kpreid force-pushed the type-str branch from d59c0a2 to d2ed8cf Compare February 12, 2025 03:01

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 20, 2025

workingjubilee mentioned this pull request Feb 20, 2025

Rollup of 12 pull requests #137347

Closed

matthiaskrgr mentioned this pull request Feb 21, 2025

Rollup of 10 pull requests #137397

Merged

bors merged commit 28164f1 into rust-lang:master Feb 21, 2025
6 checks passed

rustbot added this to the 1.87.0 milestone Feb 21, 2025

kpreid deleted the type-str branch February 25, 2025 20:43

bjorn3 reviewed Apr 1, 2025

View reviewed changes

compiler-errors mentioned this pull request Apr 22, 2025

Remove a test that never runs #140155

Closed

oli-obk mentioned this pull request Jul 4, 2025

Make TypeId const comparable #142789

Merged

		# Make `TypeId` store a reference to the name of the type, so that it can print that name.
		debug_typeid = []

Optionally add type names to TypeIds. #136148

Optionally add type names to TypeIds. #136148

Uh oh!

Conversation

kpreid commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 27, 2025

Uh oh!

jieyouxu Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joboet left a comment

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Jan 29, 2025

Uh oh!

kpreid commented Jan 29, 2025

Uh oh!

Mark-Simulacrum commented Jan 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

m-ou-se commented Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joboet commented Feb 20, 2025

Uh oh!

bors commented Feb 20, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Optionally add type names to `TypeId`s. #136148

Optionally add type names to `TypeId`s. #136148

kpreid commented Jan 27, 2025 •

edited

Loading

jieyouxu Jan 28, 2025 •

edited

Loading

m-ou-se commented Feb 12, 2025 •

edited

Loading