[PATCH] D82903: [flang] Bug fix for ambiguous references to data and functions
Pete Steinfeld via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 1 10:48:41 PDT 2020
PeteSteinfeld marked an inline comment as done.
PeteSteinfeld added inline comments.
================
Comment at: flang/lib/Semantics/resolve-names.cpp:7030
+ // not have symbols
+ ExecutionPartSkimmer{*this}.Walk(node.exec());
}
----------------
PeteSteinfeld wrote:
> tskeith wrote:
> > PeteSteinfeld wrote:
> > > 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.
> > I was referring to this call, not the one in `ResolveSpecificationParts`. Immediately above here we walk the execution parts. The will include the `ArrayElement` node. Why can't `NoteExecutablePartArrayElement` be done as part of that walk?
> Thanks for clarifying. It may be possible to do that. I'll investigate.
@tskeith , you were correct that we can handle detection of `ArrayElement` references in the main `ResolveNames` pass of the execution part. I'll be pushing a change soon with this implementation.
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