<div dir="ltr">In r214189, r214190.<div><br></div><div>Thanks,</div><div>Manman</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 28, 2014 at 5:34 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>><br>
>> Yes, it is mainly for size reasons. But you are right, we will only have one<br>
>> unspecified_type and one unspecified_parameter for each module.<br>
>> The other reason is for clarity so we know these two are trivial types<br>
>> without size, offset etc.<br>
>><br>
>> I am okay with removing DITrivialType if it is a burden to have one more<br>
>> class in our DIType hierarchy.<br>
><br>
> It really is a bit awkward to derive here - since unspecified type has<br>
> strictly /less/ functionality (hence all the assertions that were<br>
> added) - it should be further up the inheritance hierarchy, if<br>
> anywhere. And it's not /exactly/ a type, though it's convenient to<br>
> treat it as one.<br>
><br>
> We could be hackish in a different way, and treat null in the<br>
> subroutine type list as being "unspecified type" (null in the first<br>
> slot means "void return", but null in later (and only trailing)<br>
> positions in the array could be "unspecified parameters")<br>
><br>
> The "right" thing would be for there to be a type from which DIType<br>
> would derive (call it, say, DIThingsInSubroutineTypes) that we either<br>
> used directly, or had a separate derived type for<br>
> DIUnspecifiedParameters - that type (DIThingsInSubroutineTypes)<br>
> wouldn't have any of the member functions DIType has, because it<br>
> doesn't have any data/features.<br>
><br>
> But then we'd need DIThingsInSubroutineTypesRef as well, etc, etc...<br>
><br>
> I'm sort of inclined to use null here. Eric - what do you reckon?<br>
><br>
> {null} -> "void()"<br>
> {null, null} -> "void(...)"<br>
> {null, <metadata node for int>, null} -> "void(int, ...)"<br>
> {null, null, <metadata node for int>} -> invalid<br>
><br>
> Eric - what do you reckon?<br>
<br>
</div></div>Seems reasonable.<br>
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Easy to implement, just have createUnspecifiedParameter return null,<br>
> and have the two places that check for isUnspecifiedParameter check<br>
> for null instead.<br>
><br>
> Any other reasons we'd have null in a parameter type list?<br>
><br>
> But, yeah, alternatively we just use a basic DIType and don't worry<br>
> about the rest of the fields - it's a bit trickier I think (having a<br>
> non-null DIType object with a bunch of operations that are invalid -<br>
> null/non-nullness is a bit more of a clearer distinction - either<br>
> you've got all the operations or none of them).<br>
><br>
</div></div></blockquote></div><br></div>