[Lldb-commits] [PATCH] D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue

[Jim Ingham via lldb-commits]

> On Jun 27, 2019, at 3:28 PM, Alex Langford via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> 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++

Yes, that seems like the right thing to do.  Even though you can mix ObjC and C++ in an ObjC++ file, you can't mix the object models so you'll never have a method that is both ObjC & C++.  It either dispatches like ObjC or it dispatches like C++...  So the runtime gotten from the method you're stopped in's name should be right.

Jim

> 
>> 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
> 
> 
>