[Patch, Fortran] attributes for gfc_component

[Tobias Burnus]

Daniel Franke wrote:
> On Friday 15 August 2008 17:13:02 Janus Weil wrote:
>   
>> Now there are two possibilities: Either add each of these as separate
>> fields to gfc_component (like it has already been done with pointer,
>> allocatable, dimension and access), or simply reuse the
>> symbol_attributes structure. 
>>     
> Third, create a component_attribute structure.
>
> Sooner or later it will confuse people if components may have fields for 
> attributes that are never used. IMO, try to keep separate things separate.
>   

I think that is essentially the same as option 1 -- add them to 
gfc_component - one needs to copy at least 14 items from symbol_attr to 
the gfc_component (or gfc_component_attr) and back and one needs to save 
them in module.c. If one wants to reduce the number of items, one could 
refactor those common to components and other symbols and put them into 
a separate struct (non trivial).

For components one needs all attributes for function/subroutine symbols 
/ function-result symbols. One of cause does not need the specific 
attributes for dummy variables or local variables. (i.e. one does not 
need save, intent, implied_index, craypointer, use_only, is_protected, 
in_namelist, sequence.)

However, I do not see much of a difference in this regard to other 
usages of symbol_attribute. For a function result symbol I also do not 
need sequence:1 or is_main_program:1 but symbol_attribute still contains 
them.

Thus  unless we want to refactor symbol_attribute I'm really in favour 
of using it also in gfc_components. Before, one could easily save memory 
as a component had only  DIMENSION  and  POINTER (two items -> small). 
Later ALLOCATABLE and gfc_access were added.

But now we need to add at least: proc_pointer:1, function:1, 
subroutine:1, untyped:1, elemental:1, pure:1, recursive:1
I'm sure I missed some items. How about  is_c_interop:1 and is_bind_c:1. 
Does one need them? Probably!

There it already starts: If one adds an item to symbol_attributes, one 
needs to think whether it can affect procedure pointer components. If it 
does, one needs to add it to gfc_component as well and needs to copy it 
via gfc_set/get_component_attr() - and we need to store/load them in 
module.c.


In conclusion: I think it is much more maintainable to simply use 
symbol_attribute in gfc_component instead of re-implementing part of it 
and writing a conversion routines + the module saving/loading routine. 
That made only sense when we had very few attributes for components.

Tobias