import statement question

[Tobias Burnus]

Paul,

Paul Thomas wrote:
>> The following patch fixes it. But I'm not sure whether the current
>> approach of importing the symbol into the namespace of the interface
>> body is the smartest and whether the fix allows invalid code.
>>   
> It would be better, would it not, to copy the derived type symbol into
> the interface namespace...
I agree, but I didn't come up with something better.
Suggestions?

>> -  if (sym->ts.type == BT_DERIVED && sym->ns != sym->ts.derived->ns)
>> +  if (sym->ts.type == BT_DERIVED && sym->ns != sym->ts.derived->ns
>> +      && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)
>>      {
>>        gfc_symbol *s;
>>        gfc_find_symbol (sym->ts.derived->name, sym->ns, 0, &s);
>>   
> ....because this will over-ride the inhibition of host association of
> symbols
Yes, but only for symbols in the interface body.

> ie. you have to ensure that it is only imported derived types that you
> are treating this way.

I fail to come up with an example, which creates a local class-1
indentifier in an interface body as the possibilities there are very
restricted. Adding a type declaration there or using the imported symbol
as local symbol is already rejected earlier.

I believe the patch itself is correct and does not allow invalid code,
though I'm not positive. But if you have a better idea to replace the
copy the derived type symbol into the interface namespace, I'm interested.

Tobias