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