[flang] Fix name resolution bug (#158749)

When the current scope is an implied DO loop nested within a derived
type declaration, it is possible for name resolution to mistakenly
resolve a name to a component rather than to a name in the outer scope.
Fix.

Fixes #158412.

Author: klausler

flang/lib/Semantics/resolve-names.cpp

@@ -2994,12 +2994,20 @@ Symbol *ScopeHandler::FindSymbol(const Scope &scope, const parser::Name &name) {
       }
     }
     return FindSymbol(scope.parent(), name);
-  } else {
+  } else if (scope.kind() == Scope::Kind::ImpliedDos) {
+    if (Symbol * symbol{FindInScope(scope, name)}) {
+      return Resolve(name, symbol);
+    } else {
+      // Don't use scope.FindSymbol() as below, since implied DO scopes
+      // can be parts of initializers in derived type components.
+      return FindSymbol(scope.parent(), name);
+    }
+  } else if (inEquivalenceStmt_) {
     // In EQUIVALENCE statements only resolve names in the local scope, see
     // 19.5.1.4, paragraph 2, item (10)
-    return Resolve(name,
-        inEquivalenceStmt_ ? FindInScope(scope, name)
-                           : scope.FindSymbol(name.source));
+    return Resolve(name, FindInScope(scope, name));
+  } else {
+    return Resolve(name, scope.FindSymbol(name.source));
   }
 }
 
@@ -8722,7 +8730,6 @@ const parser::Name *DeclarationVisitor::ResolveName(const parser::Name &name) {
       return &name;
     }
   }
-
   if (CheckForHostAssociatedImplicit(name)) {
     NotePossibleBadForwardRef(name);
     return &name;

flang/test/Semantics/resolve127.f90

@@ -0,0 +1,7 @@
+!RUN: %flang_fc1 -fdebug-unparse %s 2>&1 | FileCheck %s
+double precision, parameter :: x = 1.0d0
+type t
+  !CHECK: REAL :: x(1_4) = [INTEGER(4)::8_4]
+  real :: x(1) = [(kind(x),j=1,1)]
+end type
+end