[PATCH] D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended.

[Zachary Turner via llvm-commits]

Another option is to simply move it into support and say that going forward
merges to libcxxabi might get more difficult. Perhaps this isn’t so bad
though. Isn’t the itanium demangler mostly complete? If the potential for
future changes to it is low, maybe this is an acceptable tradeoff. Then we
could just move it to support, use it and evolve it any way we want with no
restrictions, and when new functionality gets added to the itanium mangler
that needs to be port to libcxxabi, it’s a little more effort than a simple
copy paste because you have to think about it some.

Thoughts?
On Thu, Aug 16, 2018 at 4:16 PM Chandler Carruth via Phabricator <
reviews at reviews.llvm.org> wrote:

> chandlerc added a comment.
>
> In https://reviews.llvm.org/D50828#1203431, @zturner wrote:
>
> > If we're not going to allow code from Support to be used in the
> demangler, then I don't think we should move it to support, because it will
> be too easy for people to mess up and use code they shouldn't.
>
>
> We could easily add a unittest (or something similar) that builds and uses
> the file in the standalone mode without the Support library to ensure that
> when it gets copied into libc++abi it still works. This should be possible
> to implement both with a single file in the Support library and for a
> separate library. And regardless of which design, seem like a more reliable
> way of preserving the invariant that we want here?
>
> > Perhaps what we need are some hooks into the demangler (e.g. an
> interface defined in LLVMDemangle that exposes some virtual methods with
> default implementations), and then LLVM / Clang could override them to
> inject custom functionality.
>
> No strong feelings here, happy to let you and Richard discuss this aspect
> of the design.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D50828
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180816/77974b6b/attachment-0001.html>