This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR20880 - Failure to detect procedures encompassing own interface


Paul Richard Thomas wrote:
"Two or more accessible entities, other than generic interfaces or
defined operators, may have the same
identifier only if the identifier is not used to refer to an entity in
the scoping unit. Generic interfaces and
defined operators are handled as described in section 16.2.3. Except for
these cases, the local identifier
of any entity given accessibility by a USE statement shall differ from
the local identifiers of all other
entities accessible to the scoping unit through USE statements and
otherwise."

At the moment I fail to see whether this allows or forbids it.

The key is the "not used to refer to" in the first sentence. Clearly two modules can contain any amount of ambiguity and, indeed, must be able to do so, just as long as the ambiguous symbols are not referred to.

I agree. I recall having a conversation with Richard Maine about some particularly twisted edge case related to this, which I remember as confirming that this was allowed, though his advice (about the edge case) was also "Don't do that, even though it's legal." :)


I believe that the test should include && sym->referenced.  I will
check this tonight and will commit under the obvious rule if it's OK.

What does this do in the case where whether the symbol is referenced is unknown at compile-time? For instance, in Grigory's example module the symbol isn't referenced, but it's exported and could be referenced in some program that includes the module and is compiled later.


- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]