[libcxxabi][llvm-symbolizer] Demangler produces bad output for templated `operator<`

[jeremy-rifkin]

llvm-cxxfilt and __cxa_demangle demangle _ZltI1SEvT_S1_ as void operator<<S>(S, S). Specifically, the operator<<S> part can be problematic for tooling attempting to parse these names since this should be tokenized as operator << S >. While possible to disambiguate some cases, I think it would be better to demangle this specific case as void operator< <S>(S, S).

[llvmbot]

@llvm/issue-subscribers-tools-llvm-cxxfilt

Author: Jeremy Rifkin (jeremy-rifkin)

llvm-cxxfilt and __cxa_demangle demangle `_ZltI1SEvT_S1_` as `void operator<<S>(S, S)`. Specifically, the `operator<<S>` part can be problematic for tooling attempting to parse these names since this should be tokenized as `operator` `<<` `S` `>`. While possible to disambiguate some cases, I think it would be better to demangle this specific case as `void operator< <S>(S, S)`.

[jh7370]

I'm not convinced tooling should be relying on the demangled names, since they can be ambiguous in various ways (e.g. they might demangle to the same thing). Mangled names are the definitive source of names, since they are unambiguous by definition.

@MaskRay, do you have any thoughts?

@jeremy-rifkin, what sort of tooling are you referring to here?

[Michael137]

I'm not convinced tooling should be relying on the demangled names, since they can be ambiguous in various ways (e.g. they might demangle to the same thing)

I would agree. For example, LLDB has run into issues trying to parse/rely on demangled names in the past (e.g., #58362), and we just accepted that we can't fully rely on what the demangler is doing. In some cases LLDB uses the Itanium demangle tree when it wants to query properties/structure of demangled names (of course that might not be feasible for tooling that doesn't have access to that).

It could be possible to add an option to adjust the spacing? Though that'd be the first kind of printing option that the Itanium demangler would take AFAIK, so the infrastructure for that might not be there.

[philnik777]

While I agree that tooling probably shouldn't rely on this, I do think that it might worth changing, because I find void operator< <S>(S, S) much more readable than void operator<<S>(S, S). Even knowing the issue title it took me some time to figure out what the latter is supposed to mean.

[jh7370]

While I agree that tooling probably shouldn't rely on this, I do think that it might worth changing, because I find void operator< <S>(S, S) much more readable than void operator<<S>(S, S). Even knowing the issue title it took me some time to figure out what the latter is supposed to mean.

That's probably fair, though we'd need to make a list of cases that we want to apply that to, because I suspect there are other operators that are equally hard to read without a separating space. operator<<, for example, is arguably even worse!

[jeremy-rifkin]

@jeremy-rifkin, what sort of tooling are you referring to here?

I'm mainly looking at this in the context of things like stack trace pretty-printing, flame-graphs, etc which rely on demangled symbol name from the binary.

[dwblaikie]

Yeah, maybe just put a space unconditionalrly between any operator name and a template argument list? Doesn't seem like operator+ <S> would be a great loss/worse than operator+<S> for instance