Yea this approach is fine I guess, but I’m not really a fan of gigantic headers, so if it’s possible to use runtime polymorphism that seems better to me.  Otoh, I’m not the maintainer of the itanium demangler, so feel free to ignore :)<br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 7:09 PM Erik Pilkington via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">erik.pilkington added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D50828#1203539" rel="noreferrer" target="_blank">https://reviews.llvm.org/D50828#1203539</a>, @rsmith wrote:<br>
<br>
> I'm going to try to split this patch so it adds a generic visitation mechanism to the demangler AST, and introduce a separate layer that includes Support and builds profiling off the visitation mechanism. That seems like the only way out that meets everyone's acceptance criteria. However, I don't see any way to do that without moving all of the demangler to a public header in include/llvm (since the whole thing will need to be included from both the Demangle/ demangler and the profiling demangler). That header would only be included (and the templates in it instantiated) in two places in LLVM, but still, it'd be a 5000-line header file. If people are strongly opposed to that approach, please shout now!<br>
<br>
<br>
+1 from me! I was just writing an argument to do something like this.<br>
<br>
One more thing that I want to mention: If/when we go monorepo, then we can share code between libcxxabi and llvm the old-fashioned way. Tangling in support would just make it impossible to ever de-duplicate the demanglers.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D50828" rel="noreferrer" target="_blank">https://reviews.llvm.org/D50828</a><br>
<br>
<br>
<br>
</blockquote></div>