Looking up a type's representation by name

compiler
1

I'm working on a Rust-related research project for a lab I'm affiliated with, which involves adding some custom static analysis at the MIR level to our own fork of Rustc. A big part of this project is basically detecting whenever an expression is of a certain type, say Box<T>. My initial idea for detecting this was to perform some kind of comparison with Rustc's Ty struct, which requires that I'm able to retrieve the internal Ty representation of Box by its name, so that I can compare any types in question to the Ty I retrieve to determine whether or not they're also a Box.

My main question is: is it possible to retrieve the Ty representation of a type by name like this? I couldn't find any queries that would do that, and to be completely honest I'm not even sure if it's a good idea given my limited knowledge of how types are implemented in Rustc, so I'm mostly looking for guidance on my approach to this problem of type comparison. If this lookup-by-name isn't the best way to go about things, I'd love to hear about alternatives. I'm also aware that there will probably be some challenges/subtleties that arise from the fact that Box is generic as well.

I apologize if this isn't an appropriate topic to discuss here; if that's the case, please let me know. I mostly just figured that the Rustc internals forum would be a good place to pose a question about the internals of the compiler, even if it's for a research project that's not really related to the development of upstream Rustc.

In any case, thanks in advance for any guidance you may have! I'm happy to provide more info as needed.

2 Likes
2

Names are really a pain, because of hygiene and such.

Box specifically, though, is a lang item (Lang Items - Guide to Rustc Development). So you can get its DefId from https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/lang_items/struct.LanguageItems.html#method.owned_box or https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.require_lang_item.

If this is a research project, then the simplest way I can think of might be to mark the types you care about as Diagnostic Items - Guide to Rustc Development, which you can then find with https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.diagnostic_items.

But I'm far from an expert at this stuff. You might also want to ask in the #t-compiler/help stream on Zulip.

5 Likes
3

I am confused why do you need this? If you are working on MIR, you already have Ty. If you want to check that this Ty is Box, you call its is_box method. For types other than Box, it would be good to know how do you obtain the list of them? For example, is it an option to annotate their definition sites?

4

I would use that as well. Clippy also somewhat relies on lang and diagnostic items. I think we would be receptive to adding cases upstream for your usecase. The only limitation would be for types from outside std::

I'm guessing Box might have been just an example and they want to check against arbitrary types when they only have something like std::box::Box. Luckily for them, paths internally are canonicalized, so if they have a DefId they don't need to figure out how to transform the locally known type to their "real" type path. This might be a way to get around the problem of 3rd party crates' types.

1 Like
5

Thanks for the info! Diagnostic items sound like a very promising solution to what I'm working with, so thanks for the tip there. I'll give what you've mentioned here a try, and maybe reach out on Zulip if I run into anything else. In any case, thanks again!

6

Yeah you got it, Box was just the most well-known type I could point to for the sake of example. In reality I'm checking for the presence of a custom pointer type that we've defined ourselves, so I'm not sure if upstream would be interested in a case like this, beyond allowing types in third party crates to be marked as diagnostic items (assuming my understanding holds that only types in the Rust repo can be marked).

My current plan is probably to move the custom pointer type into its own area of either core or std in the fork I'm working off of, just to get around the lack of 3rd party crate diagnostics. If there's interest in removing that restriction, I'd love to get involved, but beyond that I'm not sure if my plan is a good fit for upstream, unfortunately.

Either way, thanks to everyone for their responses–I'm hopeful that this will give me a push in the right direction.

2 Likes
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.