[flang-commits] [flang] f8dbe79 - [flang] Don't resolve component names to components in derived-type definition scope

Peter Klausler via flang-commits flang-commits at lists.llvm.org
Sun Oct 30 13:42:35 PDT 2022


Author: Peter Klausler
Date: 2022-10-30T13:37:47-07:00
New Revision: f8dbe79cc673439db4b90cdcabcffc79348a2ca1

URL: https://github.com/llvm/llvm-project/commit/f8dbe79cc673439db4b90cdcabcffc79348a2ca1
DIFF: https://github.com/llvm/llvm-project/commit/f8dbe79cc673439db4b90cdcabcffc79348a2ca1.diff

LOG: [flang] Don't resolve component names to components in derived-type definition scope

We implemented 19.3.4p1 literally in name resolution:

  A component name has the scope of its derived-type definition. Outside the type definition,
  it may also appear within a designator of a component of a structure of that type or as a
  component keyword in a structure constructor for that type.

and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.

It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols.  Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.

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

Added: 
    

Modified: 
    flang/docs/Extensions.md
    flang/lib/Semantics/resolve-names.cpp
    flang/test/Semantics/resolve104.f90
    flang/test/Semantics/symbol14.f90

Removed: 
    


################################################################################
diff  --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 63f85baaf370..d0d715db19e8 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -478,3 +478,15 @@ end module
   standard and not allowed by most other compilers.
   If the `USE`-associated entity of the same name is not a procedure,
   most compilers disallow it as well.
+
+* Fortran 2018 19.3.4p1: "A component name has the scope of its derived-type
+  definition.  Outside the type definition, it may also appear ..." which
+  seems to imply that within its derived-type definition, a component
+  name is in its scope, and at least shadows any entity of the same name
+  in the enclosing scope and might be read, thanks to the "also", to mean
+  that a "bare" reference to the name could be used in a specification inquiry.
+  However, most other compilers do not allow a component to shadow exterior
+  symbols, much less appear in specification inquiries, and there are
+  application codes that expect exterior symbols whose names match
+  components to be visible in a derived-type definition's default initialization
+  expressions, and so f18 follows that precedent.

diff  --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index 2c21896d807b..58d31b9b5a19 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -2267,9 +2267,7 @@ Symbol *ScopeHandler::FindSymbol(const parser::Name &name) {
 Symbol *ScopeHandler::FindSymbol(const Scope &scope, const parser::Name &name) {
   if (scope.IsDerivedType()) {
     if (Symbol * symbol{scope.FindComponent(name.source)}) {
-      if (!symbol->has<ProcBindingDetails>() &&
-          !symbol->has<GenericDetails>() &&
-          !symbol->test(Symbol::Flag::ParentComp)) {
+      if (symbol->has<TypeParamDetails>()) {
         return Resolve(name, symbol);
       }
     }

diff  --git a/flang/test/Semantics/resolve104.f90 b/flang/test/Semantics/resolve104.f90
index 3b5bea458db1..d082981a40d2 100644
--- a/flang/test/Semantics/resolve104.f90
+++ b/flang/test/Semantics/resolve104.f90
@@ -33,7 +33,7 @@ module m2
     integer, kind :: dtypeParam = 4
     type(baseType(dtypeParam)) :: baseField
     !ERROR: KIND parameter value (343) of intrinsic type REAL did not resolve to a supported value
-    real(baseField%baseParam) :: realField
+    real(dtypeParam) :: realField
   end type dtype
 
   type(dtype) :: v1

diff  --git a/flang/test/Semantics/symbol14.f90 b/flang/test/Semantics/symbol14.f90
index 611c43aea1f1..2b75411bb672 100644
--- a/flang/test/Semantics/symbol14.f90
+++ b/flang/test/Semantics/symbol14.f90
@@ -1,6 +1,5 @@
 ! RUN: %python %S/test_symbols.py %s %flang_fc1
-! "Bare" uses of type parameters and components
-
+! "Bare" uses of type parameters
  !DEF: /MainProgram1/t1 DerivedType
  !DEF: /MainProgram1/t1/k TypeParam INTEGER(4)
  type :: t1(k)
@@ -18,7 +17,7 @@
   real :: b(k)
   !DEF: /MainProgram1/t2/c ObjectEntity REAL(4)
   !DEF: /MainProgram1/size INTRINSIC, PURE (Function) ProcEntity
-  !REF: /MainProgram1/t1/a
+  !DEF: /MainProgram1/a (Implicit) ObjectEntity REAL(4)
   real :: c(size(a))
   !REF: /MainProgram1/t1
   !DEF: /MainProgram1/t2/x ObjectEntity TYPE(t1(k=666_4))


        


More information about the flang-commits mailing list