[Lldb-commits] [PATCH] D59217: Fix/unify SBType comparison

[Zachary Turner via lldb-commits]

On Mon, Mar 11, 2019 at 4:15 PM Jim Ingham via lldb-commits <
lldb-commits at lists.llvm.org> wrote:

> Just to be precise: TypeImpl stores a TypePair for the static type and a
> CompilerType for the dynamic type.  These two have different meanings.
> There's no assumption about the relationship between the static and dynamic
> type.  In ObjC, the dynamic type need not even be in the same class
> hierarchy as the static type.  That's there so that if an SBValue hands out
> a type, it can represent both the static and dynamic types of the value it
> comes from.
>
> I'm not sure why the static type is a TypePair and the dynamic type is a
> CompilerType, however.
>
> The TypePair stores a TypeSP and a CompilerType that are supposed to be
> the same type.  It doesn't look like there is any way for those two to get
> out of sync, but I'm not entirely sure why it helps to have both in the
> same object.  Presumably it's caching?
>

This was what i meant.  It seems that in the case of SBType, nothing
depends on the type_sp member of the pair, only the CompilerType.

I think the reason why both are in the same object is so that if you
initialize it with a TypeSP you have a superset of functionality available
than if you initialize it from a CompilerType.  But, if nobody actually
requires this, then it simplifies the interface and makes it easier to
reason about to just store a CompilerType for the static type.

Like Greg said though, it should be easy to see if it breaks anything by
just changing the static type from TypePair to CompilerType and then fixing
up the code and seeing if anything breaks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190311/424ba281/attachment.html>