I’m using librustc in an experimental project to analyze definitions in crates, including
std. To export the findings in a format that is both human-readable and unambiguous, I’ve relied on
ctxt::item_path_str until now. However, with the current nightly, I now get some ambiguous paths, even after switching to
<u32 as num::One>::one # in core ... <u32 as core::num::One>::one # in std ... <u32 as std::num::One>::one # outside of std
The problem seems to be that
absolute_item_path_str indirectly calls
item_path_str, e.g. via
Display implementation. Is this behavior expected? I don’t expect you to change your internal APIs just for my sake, but I’m wondering whether this could also negatively affect symbol names (the only internal user of
Absolute, afaik). For example, dylibs or incremental compilation.
PS: I know that
absolute_item_path_str isn’t guaranteed to produce unique output, but I can live with some rare collisions.