[all-commits] [llvm/llvm-project] 9b2000: [flang] Fix combining cases of USE association & g...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9b200074b17af425bc4366b7b0c3ba74c1f5b89a
      https://github.com/llvm/llvm-project/commit/9b200074b17af425bc4366b7b0c3ba74c1f5b89a
  Author: Peter Klausler <pklausler at nvidia.com>
  Date:   2022-04-14 (Thu, 14 Apr 2022)

  Changed paths:
    M flang/lib/Semantics/resolve-names.cpp
    M flang/lib/Semantics/symbol.cpp
    M flang/test/Semantics/modfile07.f90
    M flang/test/Semantics/resolve17.f90

  Log Message:
  -----------
  [flang] Fix combining cases of USE association & generic interfaces

Fortran admits a few ways to have multiple symbols with the
same name in the same scope.  Two of them involve generic
interfaces (from INTERFACE or GENERIC, the syntax doesn't matter);
these are allowed to inhabit a scope with either a derived type or
a subprogram that is also a specific procedure of the generic.
(But not both a derived type and a subprogram; they could not
cohabit a scope anyway, generic or not.)

In cases of USE association, f18 needs to be capable of combining
use-associated generic interfaces with other use-associated entities.
Two generics get merged (this case was nearly correct); a generic
and a derived type can merge into a GenericDetails with a shadowed
derivedType(); and a generic can replace or ignore a use-associated
procedure of the same name so long as that procedure is already
one of its specifics.

Further, these modifications to the use-associated generic
interface must be made to a local copy of the symbol.  The previous
code was messing directly with the symbol in the module's scope.

The fix is basically a reimplementation of the member function
DoAddUse() in name resolution.

Differential Revision: https://reviews.llvm.org/D123704