[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
Thu Jul 2 16:13:21 PDT 2020
tskeith added inline comments.
================
Comment at: flang/lib/Semantics/resolve-names.cpp:5907
+ if (!symbol) {
+ symbol = currScope().FindSymbol(name.source);
+ }
----------------
PeteSteinfeld wrote:
> tskeith wrote:
> > I think if you do this in `ResolveDataRef` when we see an `ArrayElement` you don't need to call `FindScope`. The name will be resolved if it can be.
> Good thought. But I checked, and the `symbol` field of the `parser::Name` has not yet been filled in at the point. On the other hand, I realized that the lookup via the call to `FindSymbol()` always succeeds at the point because the current scope is correctly set. This let me simplify the code by eliminating the unnecessary reference to `name.symbol`.
`ResolveDataRef` is where the symbol is filled in. I'm suggesting something like this for the `ArrayElement` case in `ResolveDataRef`:
```
[&](const Indirection<parser::ArrayElement> &y) {
Walk(y.value().subscripts);
const parser::Name *name{ResolveDataRef(y.value().base)};
if (!name) {
} else if (!name->symbol->has<ProcEntityDetails>()) {
ConvertToObjectEntity(*name->symbol);
} else if (!context().HasError(*name->symbol)) {
SayWithDecl(*name, *name->symbol,
"Cannot reference function '%s' as data"_err_en_US);
}
return name;
},
```
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