[PATCH] D82903: [flang] Bug fix for ambiguous references to data and functions

[Pete Steinfeld via Phabricator via llvm-commits]

PeteSteinfeld marked 3 inline comments as done.
PeteSteinfeld added inline comments.


================
Comment at: flang/lib/Semantics/resolve-names.cpp:5885
+    if (!symbol) {
+      symbol = currScope().FindSymbol(name->source);
+    }
----------------
tskeith wrote:
> Why is this change needed? When would `FindSymbol` find the wrong symbol?
Yes.  The call to `currScope()` misses block scopes.  So if the same name is declared in a block and in the global scope, the wrong one will be found.


================
Comment at: flang/lib/Semantics/resolve-names.cpp:7030
+  // not have symbols
+  ExecutionPartSkimmer{*this}.Walk(node.exec());
 }
----------------
tskeith wrote:
> Why does this require an extra pass over the parse tree. Can't this check be done as part of `ResolveExecutionParts` where `ArrayElement` nodes are handled?
The problem I ran into was dealing with blocks and their associated scopes.  When processing the specification parts, I couldn't find symbols declared in blocks.  I tried eliminating the pass in `ResolveSpecificationParts`, but that broke processing of subprograms as dummy arguments.


================
Comment at: flang/test/Semantics/resolve93.f90:10
+    !ERROR: Cannot reference function 'str2' as data
+    print *, str2(1:9), str2(7)
+    !ERROR: 'str1' is not an array
----------------
tskeith wrote:
> It's odd that this is the same situation as line 6 but we get a different error message.
In the first case, the problem is discovered during the first skimming code walk, where the name `str` is classified as an `ObjectEntity` because we find it in a parse tree that's an `ArrayElement`.  

Then, the execution part is walked to resolve names.  During this walk, a `Pre()` function for `FunctionReference` gets executed and it converts the name `str2` to a `ProcEntity`.  This happens before the code that I added.  Then the skimming walk that I added gets executed.  It sees the parse tree for the `ArrayElement`, but the name `str2` has already been classified as a `ProcEntity` at that point.  This causes the error message to be emitted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82903/new/

https://reviews.llvm.org/D82903