import statement question

[Tobias Burnus]

Hi,

Brooks Moses wrote:
> Christopher D. Rickett wrote:
>> hi all,
>>
>> is the following code valid:
> [...]
>
> It looks valid to me.  Further, the error message that you quote is
> erroneous regardless of the validity; the more I look at it, the less
> sense it makes.
It also looks valid to me and to the other compilers I have.

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.

The patch which introduced the check is PR fortran/29232.

We currently import the symbols as follows (decl.c, gfc_match_import):
-------------------
          gfc_find_symbol (name, gfc_current_ns->parent, 1, &sym)

          st = gfc_new_symtree (&gfc_current_ns->sym_root, name);
          st->n.sym = sym;
          sym->refs++;
          sym->ns = gfc_current_ns;
-------------------

Is there a better way? Is the patch in principle ok?

(I will create a formal patch including the test case if we don't come
up with anything better.)

Tobias

Index: resolve.c
===================================================================
--- resolve.c   (revision 122189)
+++ resolve.c   (working copy)
@@ -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);