Hi all,
I’m using librustc in an experimental project to analyze definitions in crates, including core and 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 absolute_item_path_str:
<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 TraitRef's 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.