[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