[Lldb-commits] [PATCH] D54053: [NativePDB] Add the ability to create clang record decls from mangled names.

Zachary Turner via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Nov 6 08:34:55 PST 2018

zturner added a comment.

In https://reviews.llvm.org/D54053#1288415, @aleksandr.urakov wrote:

> In https://reviews.llvm.org/D54053#1286653, @zturner wrote:
> > Bleh, I think I found a problem with this approach.  Since we assume everything is a namespace, it can lead to ambiguities.  I think we need to actually consult the debug info while parsing components of the mangled name.
> Yes, it is what actually we have done in `PDBASTParser::GetDeclContextContainingSymbol`. Also I think that it is worth to remember if we already have created the class / function parent before, and do not create namespaces in this case. For example: `N0::N1::CClass::PrivateFunc::__l2::InnerFuncStruct`. We have here the `PrivateFunc` function and the `InnerFuncStruct` structure inside it. So we do not need to create the `__l2` namespace inside the `PrivateFunc` function (moreover, it is not possible to create a namespace inside a class / function).
> There is a similar problem with global and static variables and functions. Are the mangled names presented for them? Can we solve it in the same way?
> Anyway, I think that this patch is a great start!

I actually think I have a totally different solution to this that will be more robust.  It will handle the nested classes and namespaces perfectly, but not the scoped classes.  But we can deal with that later.  But it gives us the highest quality correctness level for this case, which I think is ultimately the most common (nested classes are pretty rare).  So we can try the best methods first, and fall back to other methods as needed.  I'm going to abandon this patch for now, but we'll keep it in mind for later.  I'll upload a new patch with the new approach soon.


More information about the lldb-commits mailing list