[llvm] r214111 - [Debug Info] replace DIUnspecifiedParameter with DITrivialType.

[Eric Christopher]

>>
>> Yes, it is mainly for size reasons. But you are right, we will only have one
>> unspecified_type and one unspecified_parameter for each module.
>> The other reason is for clarity so we know these two are trivial types
>> without size, offset etc.
>>
>> I am okay with removing DITrivialType if it is a burden to have one more
>> class in our DIType hierarchy.
>
> It really is a bit awkward to derive here - since unspecified type has
> strictly /less/ functionality (hence all the assertions that were
> added) - it should be further up the inheritance hierarchy, if
> anywhere. And it's not /exactly/ a type, though it's convenient to
> treat it as one.
>
> We could be hackish in a different way, and treat null in the
> subroutine type list as being "unspecified type" (null in the first
> slot means "void return", but null in later (and only trailing)
> positions in the array could be "unspecified parameters")
>
> The "right" thing would be for there to be a type from which DIType
> would derive (call it, say, DIThingsInSubroutineTypes) that we either
> used directly, or had a separate derived type for
> DIUnspecifiedParameters - that type (DIThingsInSubroutineTypes)
> wouldn't have any of the member functions DIType has, because it
> doesn't have any data/features.
>
> But then we'd need DIThingsInSubroutineTypesRef as well, etc, etc...
>
> I'm sort of inclined to use null here. Eric - what do you reckon?
>
> {null} -> "void()"
> {null, null} -> "void(...)"
> {null, <metadata node for int>, null} -> "void(int, ...)"
> {null, null, <metadata node for int>} -> invalid
>
> Eric - what do you reckon?

Seems reasonable.

-eric

>
> Easy to implement, just have createUnspecifiedParameter return null,
> and have the two places that check for isUnspecifiedParameter check
> for null instead.
>
> Any other reasons we'd have null in a parameter type list?
>
> But, yeah, alternatively we just use a basic DIType and don't worry
> about the rest of the fields - it's a bit trickier I think (having a
> non-null DIType object with a bunch of operations that are invalid -
> null/non-nullness is a bit more of a clearer distinction - either
> you've got all the operations or none of them).
>