dblaikie added a subscriber: rsmith. dblaikie added a comment. In D118812#3291303 <https://reviews.llvm.org/D118812#3291303>, @jingham wrote:
> In D118812#3291109 <https://reviews.llvm.org/D118812#3291109>, @dblaikie > wrote: > >> Any chance you might want a limit on the size of the demangled name too? >> (might be worth considering what the most densely encoded mangled name is >> (ie: what's the longest name that could be produced by a 10k long mangled >> name? and see if that's worth having another cutoff for) > > Ironically, lldb seldom cares about most of the goo in these long demangled > names. At this point, we are building up our fast-lookup "name indexes". We > really only care about extracting the fully scoped names of the methods. > When we get around to doing smart matching on overloads, we can still pull > out all the matches to the method name, and then do the overload match on the > results. That should be sufficiently efficient, and obviate the need to do > any fancy indexing based on overloads. So most of the work of demangling > these names is not being used anyway. > > So what would be the better solution for lldb on the demangling front would > be a way to tell the demangler "only extract the full method name, and don't > bother producing the argument list or return values". But I have no idea how > easy that would be in the demangler. I think there's an API level of the demangler in LLVM designed for rewriting demangled names (@rsmith created/implemented that, I think) - I'm not sure if it's structured to allow lazy parsing/stopping after you get the base name, for instance, but maybe... CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118812/new/ https://reviews.llvm.org/D118812 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
