This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: import statement question
Tobias,
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...
@@ -5656,7 +5656,8 @@
/* Check to see if a derived type is blocked from being host associated
by the presence of another class I symbol in the same namespace.
14.6.1.3 of the standard and the discussion on comp.lang.fortran. */
- 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 - ie. you have to ensure that it is only imported derived types
that you are treating this way.
Cheers
Paul