JDevlieghere marked an inline comment as done. JDevlieghere added a comment.
In D118814#3297075 <https://reviews.llvm.org/D118814#3297075>, @jingham wrote: > In D118814#3296008 <https://reviews.llvm.org/D118814#3296008>, @labath wrote: > >> This seems fine, though it's not clear to me what is the effect of this >> patch in terms of functionality. Does the "side-effect" mentioned by Jim >> still apply here, or is this NFC now? Either is probably fine, but I'd like >> to understand what is going on. It seems like it should be NFC, but does >> that mean that the demangling (and the cpu/memory cost) is delayed until the >> first operation which requests it (such as matching a breakpoint by the full >> demangled name) ? > > I haven't gone back to read our lookups in detail, but I certainly hope that > the first time we see a breakpoint on a symbol name we don't recognize, we > wouldn't go demangling every symbol name in the system. We really try to > keep mistypings from cascading into "unpack the entire world" events. Yes, this does break the ability to set breakpoints on full demangled names. Based on the code and the comments, it really looks like it was always the intention to avoid demangling the whole name, but then (accidentally?) made it work by storing it in the ConstString. The continue on line 333 is what prevents us from indexing the full name. Before this patch, `GetDemangledName` would return the cached full demanged name, which now isn't cached and would have to be computed on demand (effectively defeating the purpose of this patch and making things slower). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118814/new/ https://reviews.llvm.org/D118814 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
