[Bug fortran/47136] New: [OOP] possible name resolution problems between MODULE and INTERFACE?

[Bug fortran/47136] New: [OOP] possible name resolution problems between MODULE and INTERFACE?

[dfranke at gcc dot gnu.org]

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

           Summary: [OOP] possible name resolution problems between MODULE
                    and INTERFACE?
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dfranke@gcc.gnu.org
                CC: janus@gcc.gnu.org


In the snippet below, I believe that "ABSTRACT INTERFACE s" of "MODULE a" and
the "MODULE s" interfere with each other in an unholy way. If either is
renamed, the error goes away.

As I can not see why duplicate names like these should be invalid, I'd assume
the code as-is to be valid?!


MODULE a
  ABSTRACT INTERFACE
    SUBROUTINE s()
    END SUBROUTINE
  END INTERFACE

  TYPE, ABSTRACT :: t
  CONTAINS
    PROCEDURE(s), DEFERRED, NOPASS :: pp
  END TYPE
END MODULE

MODULE s
  USE a
END MODULE


$ gfortran-svn -c iface.f90
iface.f90:17.7:

  USE a
       1
Error: 's' must be a module procedure or an external procedure with an explicit
interface at (1)

$ gfortran-svn -v
gcc version 4.6.0 20101230 (experimental) (GCC) 

Same for
$ gfortran-4.5 -v
gcc version 4.5.3 20101230 (prerelease) (GCC)

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.01 10:57:51
     Ever Confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org 2011-01-01 10:57:51 UTC ---
Confirmed. This may be related to PR42769 (see comment #24/25). Possibly due to
module loading.

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2011-01-02 13:25:37 UTC ---
Here is a variant which gives the same error message:

MODULE a
  TYPE, ABSTRACT :: t
  CONTAINS
    PROCEDURE, NOPASS :: pp => s
  END TYPE
CONTAINS
  SUBROUTINE s()
  END SUBROUTINE
END MODULE

MODULE s
  USE a
END MODULE

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-01-02 13:33:50 UTC ---
Some related non-OOP examples:


module a
contains
  subroutine s()
  end subroutine
end module

module s
  use a
contains
  subroutine sub()
    call s
  end subroutine
end 


gives:

    call s
          1
Error: Name 's' at (1) is an ambiguous reference to 's' from current program
unit


Example #2:


module a
contains
  subroutine s()
  end subroutine
end module

module m
  use a
contains
  subroutine s()
  end subroutine
end 


gives:

  subroutine s()
              1
test.f90:8.7:

  use a
       2
Error: Procedure 's' at (1) is already defined at (2)


Are these examples actually valid or invalid? Can someone give the relevant
quotes from the standard?

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[dfranke at gcc dot gnu.org]

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

--- Comment #4 from Daniel Franke <dfranke at gcc dot gnu.org> 2011-01-02 13:47:41 UTC ---
(In reply to comment #3)
> Some related non-OOP examples:
[...]
> Are these examples actually valid or invalid? Can someone give the relevant
> quotes from the standard?

Lahey's online source checker rejects both examples with similar messages. It
doesn't know OOP to test, but one could think that my initial example is
invalid after all?!

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-01-02 14:46:34 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Some related non-OOP examples:
> [...]
> > Are these examples actually valid or invalid? Can someone give the relevant
> > quotes from the standard?
> 
> Lahey's online source checker rejects both examples with similar messages.

So do openf95 and pathf95.


> It
> doesn't know OOP to test, but one could think that my initial example is
> invalid after all?!

I agree that it may be invalid, but one should check the exact wording in the
standard.

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-01-02 15:19:10 UTC ---
(In reply to comment #5)
> > It
> > doesn't know OOP to test, but one could think that my initial example is
> > invalid after all?!
> 
> I agree that it may be invalid, but one should check the exact wording in the
> standard.

Yes, after a look in the standard I would say that is invalid according to F08,
chapter 16.3.1, sentence #2:

"Within its scope, a local identifier of an entity of class (1) or class (4)
shall not be the same as a global identifier used in that scope unless [...]"

Class (1) contains all sorts of named variables and procedures, including
abstract interfaces. The exceptions which I elided in the above statement do
not apply. The only question is whether a module counts as "used" in it's own
scope, which I would answer with yes.

Therefore I think already the following reduction of comment #0 is invalid:

MODULE a
  ABSTRACT INTERFACE
    SUBROUTINE s()
    END SUBROUTINE
  END INTERFACE
END MODULE

MODULE s
  USE a
END MODULE

Within the scope of module "a" everything is fine, since the module "s" is not
used. Within the scope of module "s", however, the subroutine "s" is a local
identifier (by means of use association) and conflicts with the global
identifier of module "s" itself. Right?

[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |accepts-invalid

--- Comment #7 from janus at gcc dot gnu.org 2011-01-02 15:21:34 UTC ---
(In reply to comment #6)
> Within the scope of module "a" everything is fine, since the module "s" is not
> used. Within the scope of module "s", however, the subroutine "s" is a local
> identifier (by means of use association) and conflicts with the global
> identifier of module "s" itself. Right?

By this reasoning the PR is actually of the type "accepts-invalid" and not
"rejects-valid".

[Bug fortran/47136] local identifier shall not be the same as a global identifier

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[OOP] possible name         |local identifier shall not
                   |resolution problems between |be the same as a global
                   |MODULE and INTERFACE?       |identifier

--- Comment #8 from janus at gcc dot gnu.org 2011-01-02 15:24:10 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Within the scope of module "a" everything is fine, since the module "s" is not
> > used. Within the scope of module "s", however, the subroutine "s" is a local
> > identifier (by means of use association) and conflicts with the global
> > identifier of module "s" itself. Right?
> 
> By this reasoning the PR is actually of the type "accepts-invalid" and not
> "rejects-valid".

... and unrelated to OOP.

[Bug fortran/47136] local identifier shall not be the same as a global identifier

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-01-09 18:12:38 UTC ---
cf. also PR 47203, which is basically a duplicate of this one

[Bug fortran/47136] local identifier shall not be the same as a global identifier

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-07 22:21:49 UTC ---
(In reply to comment #7)
> By this reasoning the PR is actually of the type "accepts-invalid" and not
> "rejects-valid".

It seems to me that all the cases presented here (comment #0, comment #2,
the two cases in comment #3, comment #6) are invalid.
Thus it's a rejects-invalid, in other words not a bug.

[Bug fortran/47136] local identifier shall not be the same as a global identifier

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-10 15:03:04 UTC ---
(In reply to comment #10)
> (In reply to comment #7)
> > By this reasoning the PR is actually of the type "accepts-invalid" and not
> > "rejects-valid".
> 
> It seems to me that all the cases presented here (comment #0, comment #2,
> the two cases in comment #3, comment #6) are invalid.
> Thus it's a rejects-invalid, in other words not a bug.

Closing as per the reason above.