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. https://reviews.llvm.org/D54053 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
