<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 4:15 PM Jim Ingham via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org">lldb-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
I'm not sure why the static type is a TypePair and the dynamic type is a CompilerType, however.<br>
<br>
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?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>