jingham added a comment. In D63240#1561488 <https://reviews.llvm.org/D63240#1561488>, @xiaobai wrote:
> @jingham: Okay, so I tried to do what you suggested and that solution doesn't > work because of ObjC++. After looking into it, it looks like Variable and > Function just ask the CompileUnit for the language type instead of > determining it themselves meaning that we determining the Variable's language > boils down to asking the CompileUnit for its language. That can probably be > improved, but I think that just relying on the SymbolContextScope alone isn't > yet sufficient. I think it would be worth it to ask the SymbolContextScope > before trying all the loaded language runtimes though. Would you be okay with > that solution? That's unfortunate. For ObjC++ CompUnits we should get the language from the function name: it's either a C++ mangled name (language => , or an ObjC name... One way to solve this would be an ObjC++ language runtime which dispatches to the ObjC and C++ ones as is appropriate. I'm not sure whether that would always be correct, but it would provide a more explicit way to get this right. OTOH, that's a lot more work... Is your suggestion to say that if the value IS whitelisted for the SymbolContextScope language, then we're done, otherwise we ask all the runtimes? Asking C, C++ & ObjC in an ObjC++ frame is not really right - it would fail my contrived example above - but seems like it has a low probability of getting us into trouble. But if you are in a ObjC++ file, you certainly don't want to ask the Swift LanguageRuntime whether it whitelists the symbol. Those are entirely incompatible languages and you shouldn't be asking Swift questions about any C-family language frame. Perhaps a more precise version of your suggestion would be that if your SymbolContextScope language is a C-family language, we ask all the other C Family language runtimes, but not the orthogonal languages. We don't have this problem of intermixable "language's" with Swift (and probably not with Rust...) or really anything else sensible. There's just one language and you can't intermix it with code from another language... But if we did we could add the notion of language families more generally. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63240/new/ https://reviews.llvm.org/D63240 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
