xiaobai added a comment. In D63240#1561531 <https://reviews.llvm.org/D63240#1561531>, @jingham wrote:
> 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... I'm going to try to modify `Function::GetLanguage` to see if it can figure out the language based on the mangled name before it asks the compilation unit. I think that could potentially solve the issue with ObjC++ > 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... This could possibly work, but it feels like the wrong abstraction. Creating a LanguageRuntime for a language with no runtime library to work around the fact that it uses two runtimes for different languages is just masking the issue. > 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? Yup! I personally don't think that asking every language runtime is that big of a deal, but I recognize that I could be wrong about that. > 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. This idea isn't super terrible imo, but you're right here: Asking runtimes of other languages in the same family isn't right even if it has a lower probability of getting us into trouble. It will work until it doesn't. 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
