[Lldb-commits] [lldb] [lldb][DWARFASTParserClang] Adjust language type for conflicting Objective-C++ forward declarations (PR #130768)

[Michael Buch via lldb-commits]

Michael137 wrote:

> I'm not sure how creating a new type would help, since at that point the c++ type already exists and could be referred to from a bunch of places. I was imagining we would just recognise that we did not find a _**C++**_ definition for this type and then do whatever we do when we don't find a definition (leave the type incomplete? forcefully complete it?...). Later, if we reach the type through an ObjC declaration, we find the ObjC defintion and complete it using that.
> 
> I think the tricky part is what happens with types like your `struct Request { NSString * m_request;};`. If we parse the definition of `Request` from a c++ unit, it will end up referring the the (incomplete) C++ version of `NSString`, which will prevent us from inspecting it, even if we happen to be in objc code. It might be possible to do some switcheroos in the AST importer, similar to how we replace a "forcefully completed" type from one module with an actual definition from another one. Or we could say people get what they deserve (I don't know how much you care about actually supporting this use case vs. simply not crashing).

Good point, yea ideally we do want to support showing the value. Unfortunately that's something users have been relying upon. Modelling this similar to how we do forceful completion logic hasn't crossed my mind, but now I'm more inclined to go with the DWARF search route you suggested

> What would help is if we could short-circuit this code in the (common, on linux) situation where you don't have any ObjC code in your module. I'm not sure if we have a way to do that. (I don't know if we're currently parsing all CU dies, but if we are, we could check if any of them is an ObjC unit). I also think the FindTypes call is unnecessarily heavy (and dangerously recursive) for this. Since, in this world, we want to treat the two types as equivalent, I don't think we need to find all possible definitions of that type. I think it should be sufficient to settle on a canonical definition for the type (per the ODR rule and all), so we can just pick the first one we find. And we can do the search at the DWARF DIE level -- and then also record the definition die in the unique type map, so that we pick the same one when its time to complete the type.

Essentially you're suggesting going back to pre-https://github.com/llvm/llvm-project/pull/90663, but only if we have ObjC/ObjC++ CUs in the current module? Seems sensible to me. Will also help prevent similar issues from creeping up in the future

https://github.com/llvm/llvm-project/pull/130768