zequanwu added a comment. In D133446#3786561 <https://reviews.llvm.org/D133446#3786561>, @labath wrote:
> In D133446#3780961 <https://reviews.llvm.org/D133446#3780961>, @zequanwu > wrote: > >> In D133446#3779600 <https://reviews.llvm.org/D133446#3779600>, @labath wrote: >> >>> I believe that this fixes the crash, but the names of generated functions >>> still look fairly weird. Could we create them using their mangled name >>> instead? That way, someone might actually call them, if he was so inclined. >> >> It looks like they don't have mangled name stored in pdb. > > Hmm.. That's unfortunate. In that case, I'm wondering if this shouldn't be > handled somehow directly inside `MSVCUndecoratedNameParser`. What does the > function return right now? Do you think that result is going to be useful for > other users of that class? `MSVCUndecoratedNameParser` expects a undercoated name of a entity(class, function, variable, etc) and returns the a pair of {pointer to parent decl context, base name of the entity}. This is the only way we use to get enclosing context for a given entity. > Also, I'm still continuing to be amazed (and scared) by the amount of name > parsing that is going on here. Have you checked that there's no better way to > associate an entity with its enclosing context? If the entity is a global variable, we don't have any other ways to know if its enclosing context is record or namespace. If the entity is record or function, then we can know if its enclosing context is a record by looking at its type info but need to fall back to parse name again if it's inside a namespace. The issue is there isn't a way to represent namespaces in PDB, and they are just embedded into the name strings. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133446/new/ https://reviews.llvm.org/D133446 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
