search for: ditypedarray

...; DIDescirptors, we can make DIArray an array of DIDescriptorRef. >> > I don't think it is a good idea to add DIDescriptorRef (it makes our >> > types >> > loose) and am not sure about the 2nd condition. >> > >> > So I proposed to add DITypeArray (or DITypedArray<DITypeRef> as David >> > suggested, where all elements are DITypeRef), >> > DICompositeType::getTypeArray() will return DITypeArray and >> > DITypeArray::getElement(unsigned) will return DITypeRef. >> > >> > This is actually more complicated than I...

...and all elements currently inside DIArray are > DIDescirptors, we can make DIArray an array of DIDescriptorRef. > I don't think it is a good idea to add DIDescriptorRef (it makes our types > loose) and am not sure about the 2nd condition. > > So I proposed to add DITypeArray (or DITypedArray<DITypeRef> as David > suggested, where all elements are DITypeRef), > DICompositeType::getTypeArray() will return DITypeArray and > DITypeArray::getElement(unsigned) will return DITypeRef. > > This is actually more complicated than I thought, not all DICompositeType's >...

...;d need to make DITypeRef's ctor public so it could be used here. Not suggesting that's ideal, though. 2) If we're going to fix DIArray apparent type safety (it's not safe - just convenient), perhaps we could just template it? (to avoid churn, we could leave DIArray as a typedef of DITypedArray<DIDescriptor> for example, and then have DITypedArray<DITypeRef> which is your DITypeArray (again, provided via typedef)). It's so small though, that I'm not too fussed if we write it out again as you've proposed. - David > > Thanks, > Manman > >> >&gt...

We still have access to types via MDNodes directly and the assertion that assumes all accesses to DITypes are accessing the resolved DIType will fire i.e assert(Ty == resolve(Ty.getRef())) One example is the access to DIType via DIArray in SubroutineType. If all elements in the type array are DITypes we can create a DITypeArray and use that for SubroutineType's type array instead. But we