This is an archive of the discontinued LLVM Phabricator instance.

[flang] Handle multiple USE statements for the same module
ClosedPublic

Authored by PeteSteinfeld on Jun 11 2021, 9:52 AM.

Details

Summary

It's possible to have several USE statements for the same module that
have different mixes of rename clauses and ONLY clauses. The presence
of a rename cause has the effect of hiding a previously associated name,
and the presence of an ONLY clause forces the name to be visible even in
the presence of a rename. We were not correctly handling this hiding.

I fixed this by keeping track of the names that appear on rename and ONLY
clauses. Then, when processing the USE association of a name, I check to see
if it previously appeared in a rename clause and not in a USE clause. If so, I
remove its USE associated symbol. Also, when USE associating all of the names
in a module, I do not USE associate names that have appeared in rename clauses.

I also added a test.

Diff Detail

Event Timeline

PeteSteinfeld created this revision.Jun 11 2021, 9:52 AM
PeteSteinfeld requested review of this revision.Jun 11 2021, 9:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 11 2021, 9:52 AM
PeteSteinfeld edited the summary of this revision. (Show Details)Jun 11 2021, 9:55 AM
PeteSteinfeld added a project: Restricted Project.
klausler added inline comments.Jun 11 2021, 11:02 AM
flang/lib/Semantics/resolve-names.cpp
2530

Symbol::name() returns a `SourceName (== parser::CharBlock); how does this reference declaration even compile?

6457

Might be better in ResolveNamesVisitor::Pre(const parser::SpecificationPart &x) after (or before) the walk of the useStmts. FinishSpecificationPart() has multiple call sites and things might be more clear if you did this use-stmt clean-up (or set-up) at the one place that deals with the list of use-stmts.

PeteSteinfeld added inline comments.Jun 11 2021, 12:02 PM
flang/lib/Semantics/resolve-names.cpp
2530

Good catch. I can only think that the C++ compiler was constructing a parser::Name in place and then creating a reference to it. I'll fix it.

6457

Good idea. I'll make it happen.

Responding to Peter's comments.

klausler accepted this revision.Jun 11 2021, 12:11 PM
This revision is now accepted and ready to land.Jun 11 2021, 12:11 PM
PeteSteinfeld edited the summary of this revision. (Show Details)Jun 11 2021, 12:28 PM
This revision was landed with ongoing or failed builds.Jun 11 2021, 12:30 PM
This revision was automatically updated to reflect the committed changes.