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

[Jim Ingham via lldb-commits]

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?

Jim




> On Mar 11, 2019, at 10:32 AM, Zachary Turner via Phabricator via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> zturner added a comment.
> 
> SBType storing a pair of CompilerType and TypeSP seems like a very confusing interface and like it will be very easy to misuse or violate assumptions (perhaps even assumptions that nobody knows exists).  Why exactly is this necessary?
> 
> As far as I can tell, `SBType` uses `TypeImpl`, which supports having a `CompilerType`, a `TypeSP`, or both, but I cannot find any client of `TypeImpl` which actually depends on the `TypeSP` being set.  Perhaps we can just delete support for `TypeSP` from `TypeImpl` entirely.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D59217/new/
> 
> https://reviews.llvm.org/D59217
> 
> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits