[libc++abi] Why is cxa_demangle.h a public header?

What's the point of having libcxxabi/include/cxa_demangle.h?
Everything in __cxxabiv1::__libcxxabi's visibility is limited to
hidden anyway, so it's only usable within libc++abi (and maybe
libc++), but nothing else makes use of it currently.

Also, it seems to bloat libc++abi a lot, at least on OpenBSD. If I
move the declarations from cxa_demangle.h into cxa_demangle.cpp and
than change the __libcxxabi namespace into an anonymous namespace, it
cuts libc++.so (statically linked against libc++abi) from 1655653
bytes of text to just 1292112 bytes.

What's the point of having libcxxabi/include/cxa_demangle.h?
Everything in __cxxabiv1::__libcxxabi's visibility is limited to
hidden anyway, so it's only usable within libc++abi (and maybe
libc++), but nothing else makes use of it currently.

Because when I was first asked to write the demangler I was also asked to have it create a syntax tree and expose that syntax tree for use by the compiler and/or debugger.

That design hasn't worked out. I'm currently working on an alternative. A tool for the compiler and/or debugger could still be done, but it makes more sense to have that be a separate tool, as opposed to bundling it into the demangler.

Also, it seems to bloat libc++abi a lot, at least on OpenBSD. If I
move the declarations from cxa_demangle.h into cxa_demangle.cpp and
than change the __libcxxabi namespace into an anonymous namespace, it
cuts libc++.so (statically linked against libc++abi) from 1655653
bytes of text to just 1292112 bytes.

I'm hoping to get rid of this shortly.

Howard

Because when I was first asked to write the demangler I was also asked to have it create a syntax tree and expose that syntax tree for use by the compiler and/or debugger.

That design hasn't worked out. I'm currently working on an alternative. A tool for the compiler and/or debugger could still be done, but it makes more sense to have that be a separate tool, as opposed to bundling it into the demangler.

Makes sense. Thanks for the explanation!

I'm hoping to get rid of this shortly.

Do you have a timeline for this or any notes about your new plans? Is
it still worth sending patches against the current code?

Days not weeks. I haven't looked at your patches yet, but they are registered on my to-do list which has gotten rather lengthy while I work on the demangler.

The parsing code is staying approximately the same, modulo bug fixes and C++11 additions. Everything having to do with the syntax tree (everything derived from __node) is gone. Instead the parsing is generating a stack of pairs of strings. At parsing end the stack should be size 1, and the concatenation of the two strings in the pair is the demangled string.

The pair exists to aid demangling references/pointers to functions/arrays. The functions/arrays demangle into a first part and second part, and pointers/references get inserted in between the two parts.

Parameter packs demangle to a stack of string_pairs of length 0 or more.

Substitutions are stored as a vector of stacks of string pairs. This is necessary to properly store a parameter pack as a substitution.

Template parameters are stored as a stack of substitutions.

What would help most right now is code examples which mangle names which the current demangler does not handle. For example I am currently creating a code example that will mangle an expression involving nullptr.

Howard

Got that one:

template <bool b>
struct X
{
    X();
};

// _Z1fIiEDTeqfp_LDnEEPT_ -> decltype((fp) == (std::nullptr_t)) f<int>(int*)
template <class T>
auto
f(T* p) -> decltype(p == nullptr)
{
    return p == nullptr;
}

void
test()
{
    f<int>(nullptr);
}

Howard

Days not weeks. I haven't looked at your patches yet, but they are registered on my to-do list which has gotten rather lengthy while I work on the demangler.

Great, SGTM. Thanks too for explaining the new approach.

What would help most right now is code examples which mangle names which the current demangler does not handle. For example I am currently creating a code example that will mangle an expression involving nullptr.

I'll see what I can do, though my knowledge about name mangling is
pretty limited to just what c++filt can already handle today, and
libc++abi's current test suite already seems well beyond what c++filt
can handle.