[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

["janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47805

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org 2011-02-19 10:41:13 UTC ---
(In reply to comment #0)
> Overriding a TBP seems to OK, if the TBP is hidden through accessibility
> (PRIVATE).

Huh, tricky thing.



> The first example given in the file is rejected with:
> 
>       PROCEDURE,NOPASS :: p => p2 ! (2).
>                1
> Error: 'p' at (1) must have the same number of formal arguments as the
> overridden procedure


One can get rid of this error message e.g. by ... (warning: not regtested)


Index: class.c
===================================================================
--- class.c     (revision 170290)
+++ class.c     (working copy)
@@ -639,21 +639,24 @@
   res = gfc_find_symtree (root, name);
   if (res && res->n.tb && !res->n.tb->error)
     {
-      /* We found one.  */
-      if (t)
-       *t = SUCCESS;
-
       if (!noaccess && derived->attr.use_assoc
          && res->n.tb->access == ACCESS_PRIVATE)
        {
          if (where)
-           gfc_error ("'%s' of '%s' is PRIVATE at %L",
-                      name, derived->name, where);
+           {
+             gfc_error ("'%s' of '%s' is PRIVATE at %L",
+                        name, derived->name, where);
+             return res;
+           }
+       }
+      else
+       {
+         /* We found one.  */
          if (t)
-           *t = FAILURE;
+           *t = SUCCESS;
+
+         return res;
        }
-
-      return res;
     }

   /* Otherwise, recurse on parent type if derived is an extension.  */
Index: resolve.c
===================================================================
--- resolve.c   (revision 170290)
+++ resolve.c   (working copy)
@@ -11194,8 +11194,8 @@
   if (super_type)
     {
       gfc_symtree* overridden;
-      overridden = gfc_find_typebound_proc (super_type, NULL,
-                                           stree->name, true, NULL);
+      overridden = gfc_find_typebound_proc (super_type, NULL, stree->name,
+                                           false, NULL);

       if (overridden && overridden->n.tb)
        stree->n.tb->overridden = overridden->n.tb;



However, one then gets different results than indicated in (3)-(5), i.e.
gfortran always calls 'p2'. It seems our current run-time mechanisms are not
able to cope with this case.

The only way I can see out of this is to resolve the call in 'do_p' not to the
polymorphic version 'x->_vptr->p', but to a static call to the subroutine 'p'
(since 'p' is effectively not overridable, at least not outside the module).

But then it gets really tricky if we put 't2' in the same module. Then 'p'
*will* be overridden, and we have to get back to the dynamic vtable call again
to get it right.

Then be so nasty to add another type 't3' in a different module, which defines
a new TBP 'p' which does *not* override t1%p. And, bang!, we're in trouble
again.

So, I'm clueless. Does it help to put the type-name into the binding name? Say,
have the call in 'do_p' resolve to 'x->_vptr->t1_p' (to honor the fact that the
base type for the call is t1).