[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