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
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.
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
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?
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
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.
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!
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
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.