v0 demangling doesn't print everything

[RazrFalcon]

_RINvMs3_NtCseLbVHCvmZda_5alloc3stre7replaceReECsh2y0CdybKMG_11cargo_bloat

is parsed as

<str>::replace::<&str>

• rustc-demangle master
• rustc 1.38.0-nightly (60960a260 2019-08-12)

[alexcrichton]

cc @eddyb

[eddyb]

@RazrFalcon I don't understand what the report/question is.
_RINvMs3_NtCseLbVHCvmZda_5alloc3stre7replaceReECsh2y0CdybKMG_11cargo_bloat is:

• path: I(Nv(M(s3_ Nt(C(seLbVHCvmZda_ 5alloc) 3str) e) 7replace))[R(e)]E
  • path syntax: C is crate, N is concatenation, M is inherent impl
  • type syntax: I is generic args, R is &, e is str
• instantiating crate: C(sh2y0CdybKMG_ 11cargo_bloat)

If rustc-demangle had an ultra-verbose mode, it would print something like:
alloc::str::<impl str>::replace::<&str> /* instantiated by cargo_bloat */
(plus disambiguators)

Is that what you're after?

[RazrFalcon]

@eddyb Yes, I thought that rustc-demangle parses everything. Is there a reason to skip some parts?

[eddyb]

It parses those parts, but the output would be highly verbose if they were printed (and historically the only control over verbosity has been to show or hide the disambiguating hashes).
They are mostly included in the mangling to avoid conflicts (especially the "instantiating crate" part), not for demangler consumption.

However, I admit it would sometimes be helpful to see those details if we could avoid inconveniencing most users with them.

[RazrFalcon]

I see now. I've enabled the more verbose mode and it's really redundant. But it's helpful for cases like in the main post.

[RazrFalcon]

Is there a way to enable instantiating crate or is it not implemented at all? It would be very useful for cargo-bloat.

[eddyb]

@RazrFalcon You can't enable the impl path (alloc::str::impl#5) nor the instantiating crate right now - I agree it would be useful, but I'm worried it would be too noisy to add them to the current verbose mode (which shows the disambiguating hashes).

If I may ask, what are you using the mangled symbol for, in cargo-bloat?

[RazrFalcon]

I'm using a custom fork in cargo-bloat, so there is no need to add it to this crate. Also, looks like even without instantiating crate part the results are pretty good when impl is enabled. So I don't need it.

If I may ask, what are you using the mangled symbol for, in cargo-bloat?

I'm showing them. Or did I misunderstood the question?

[eddyb]

I'm showing them.

Ah, so this is to better pinpoint where a definition is coming from?

Have you considered debuginfo? It should already have the type parameter information (even without the new mangling format) and it has source information that the symbol is lacking.

[RazrFalcon]

No, I'm simply looking for symbols in rlib dependencies and fallback to a crate name parsed from a symbol.

I'm not sure how hard it would be to parse it. Also I'm not sure how much information will be preserved in a release build. This is definitely something that I should investigate.

[programmerjake]

#37 would probably help out for future features that fix this bug.