RFC: Plan to implement FINAL (with polymorphism)

[Daniel Kraft]

Hi Paul,

thanks for your comments!

Paul Richard Thomas wrote:
>> Some questions I have:
>>
>>  * This destructor table will be similar to the vtable structures, I guess;
>> thus, I think we will generate a definition in the compilation-unit where
>> the type is defined.  This is probably what the vtable does, too?
> 
> There is no need for a destructor table.  Use the vtable for CLASS
> enties; the FINAL subroutine is just a specialized generic subroutine.

Well yes, this was meant in the case that we have several destructor 
methods for different ranks -- and I did not want to add 15 pointers (or 
the like) to the vtable.  ALthough thinking about it, there's only one 
vtable per type not per CLASS object, right?  So then you're right, we 
probably should add this directly to the vtable instead.

> I suggest that, for this purpose, a 'final' field be inserted in
> gfc_symbol (if it has not been already!) and that the call be resolved
> as any other generic call.

We do not only have to call the correct FINAL procedure but do a lot 
more for finalization -- i.e., finalizing the components and the 
super-type hierarchy.

BTW, I forgot about this in the first email:  It seems that deallocation 
of ALLOCATABLE components does not yet work with polymorphic entities; 
at least I got a memory leak reported by valgrind for a program only 
using ALLOCATABLE.  This seems to be similar to finalization, and I hope 
that we can switch the whole of allocatable component deallocation over 
to the finalization framework.  But as I wrote, I think it is 
unfortunately more complex than just calling the correct FINAL procedure 
-- there needs to be also a lot of compiler generated code, and this 
also depends on the dynamic type; thus my suggestion to create a 
destructor routine that does "calling the FINAL plus more" and do vtable 
dispatch to that one.

>>  * I have the impression that we need to generate destructor functions for
>> each possible rank, not only those that are actually used -- because we do
>> not know in advance all places where a type currently compiled may be used.
>>  Or can we avoid this?
> 
> Yes you can: see the FINAL description in the F2003.  See 4.  TKR must
> be respected or the FINAL subroutine must be elemental.

Well, I read line 8 below such that there need not be a matching 
procedure but in that case no user-provided FINAL will be called.  This 
is however completely valid -- and we still have to perform steps (2) 
and (3) below.

> 1 4.5.5.1 The finalization process
> 2 Only finalizable entities are finalized. When an entity is
> finalized, the following steps are carried out
> 3 in sequence:
> 4 (1) If the dynamic type of the entity has a final subroutine whose
> dummy argument has the
> 5 same kind type parameters and rank as the entity being finalized, it
> is called with the entity
> 6 as an actual argument. Otherwise, if there is an elemental final
> subroutine whose dummy
> 7 argument has the same kind type parameters as the entity being
> finalized, it is called with
> 8 the entity as an actual argument. Otherwise, no subroutine is called
> at this point.
> 9 (2) Each finalizable component that appears in the type definition
> is finalized. If the entity
> 10 being finalized is an array, each finalizable component of each
> element of that entity is
> 11 finalized separately.
> 12 (3) If the entity is of extended type and the parent type is
> finalizable, the parent component is
> 13 finalized.

This is precisely what I meant above, in that there is more than just a 
call to the correct FINAL routine.

Yours,
Daniel

-- 
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri