[m-rev.] for post-commit review: allocate type_info vars separately from initialization

[Zoltan Somogyi]

2022-04-20 14:44 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:

>> > compiler/polymorphism_type_info.m:
>>     Delete both variants of init_type_info_var, which both allocated
>>     a new variable to hold a type_info and also create the code to
>>     assign the type_info value to it. Replace it with the service predicate
>>     that only the latter task, requiring the former to be done by its callers.
> 
> If you haven't yet pushed this:
> 
>     that only *performs* the latter task

Alas, I have.

>>      % The first variable in ArgVars should be bound to the type_ctor_info
>>      % for Type's principal type constructor. If that type constructor is
>> -    % variable arity, the next variable in ArgVars should be bound to an
>> -    % integer giving Type's actual arity. The remaining variables in
>> -    % ArgVars should be bound to the type_infos or type_ctor_infos giving
>> -    % Type's argument types.
>> +    % variable arity, and we are not targeting Java, the next variable
> 
> Unrelated to this diff: why is Java a special case here?
> (It seems unusual that is is not Java *and* C#, given that those backends
> are quite similar in most respects.)

TypeInfo_Struct.java has no constructor that takes an arity argument.
The comment there about it says that (a) it is not needed, because the
constructor can compute the arity for itself, and (b) it is not allowed by
Java 1.7 :-) The fact that the two fields in that structure are a (reference to)
a type_ctor_info structure and an array of type_infos means that the
array records the arity whether you want to or not.

I have not looked at the C# version.

> That looks fine otherwise.

Thanks.

Zoltan.