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

Tim Keith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 30 13:36:21 PDT 2020


tskeith added a comment.

Would it be worthwhile adding flags to symbols to indicate that they are assumed to be functions or data based on their usage (as opposed to explicit declarations)?

Then we could give better error messages like "Cannot access 'foo' as an array as it was previously called as a function" and "Cannot call 'foo' as a function as it was previous accessed as an array".



================
Comment at: flang/lib/Semantics/resolve-names.cpp:5885
+    if (!symbol) {
+      symbol = currScope().FindSymbol(name->source);
+    }
----------------
Why is this change needed? When would `FindSymbol` find the wrong symbol?


================
Comment at: flang/lib/Semantics/resolve-names.cpp:7030
+  // not have symbols
+  ExecutionPartSkimmer{*this}.Walk(node.exec());
 }
----------------
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?


================
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
----------------
It's odd that this is the same situation as line 6 but we get a different error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82903





More information about the llvm-commits mailing list