[flang] Compile the output of -fdebug-unparse-with-modules #135696
Conversation
The output of a compilation with the -fdebug-unparse-with-modules option comprises its normal unparsed output along with the regenerated contents of any modules that were required from module files. This is handy for producing stand-alone test cases. The modules' contents are generated by the same code that writes module files, so they can contain some USE associations to private entities in other modules that are necessary to complete local declarations, usually initializers. Such USE associations to private entities are not flagged as fatal errors when modules are read from module files, but they currently are caught when the output produced by this option is being read back in to the compiler. Handle this case by softening the error to a warning when one module uses a private entity from another with an alias containing the non-conforming '$' character. (I could have omitted the message altogether, but there are other valid warnings that will occur due to undefined function result variables; further, I didn't want to provide a general hole around the protection of private names.)
llvmbot
added
flang
|
@llvm/pr-subscribers-flang-semantics Author: Peter Klausler (klausler) ChangesThe output of a compilation with the -fdebug-unparse-with-modules option comprises its normal unparsed output along with the regenerated contents of any modules that were required from module files. This is handy for producing stand-alone test cases. The modules' contents are generated by the same code that writes module files, so they can contain some USE associations to private entities in other modules that are necessary to complete local declarations, usually initializers. Such USE associations to private entities are not flagged as fatal errors when modules are read from module files, but they currently are caught when the output produced by this option is being read back in to the compiler. Handle this case by softening the error to a warning when one module uses a private entity from another with an alias containing the non-conforming '$' character. (I could have omitted the message altogether, but there are other valid warnings that will occur due to undefined function result variables; further, I didn't want to provide a general hole around the protection of private names.) Full diff: https://github.com/llvm/llvm-project/pull/135696.diff 3 Files Affected:
diff --git a/flang/docs/ModFiles.md b/flang/docs/ModFiles.md
index cde2e4218d6fd..dd0ade5cebbfc 100644
--- a/flang/docs/ModFiles.md
+++ b/flang/docs/ModFiles.md
@@ -98,7 +98,14 @@ Entities that have been included in a module by means of USE association
are represented in the module file with `USE` statements.
Name aliases are sometimes necessary when an entity from another
module is needed for a declaration and conflicts with another
-entity of the same name.
+entity of the same name, or is `PRIVATE`.
+These aliases have currency symbols (`$`) in them.
+When a module
+is parsed from a module file, no error is emitted for associating
+such an alias with a `PRIVATE` name.
+A module parsed from another source file that is not a module file
+(notably, the output of the `-fdebug-unparse-with-modules` option)
+will emit only warnings.
## Reading and writing module files
diff --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index 74367b5229548..7ec6252530d55 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -3325,9 +3325,19 @@ ModuleVisitor::SymbolRename ModuleVisitor::AddUse(
// Privacy is not enforced in module files so that generic interfaces
// can be resolved to private specific procedures in specification
// expressions.
- Say(useName, "'%s' is PRIVATE in '%s'"_err_en_US, MakeOpName(useName),
- useModuleScope_->GetName().value());
- return {};
+ // Local names that contain currency symbols ('$') are created by the
+ // module file writer when a private name in another module is needed to
+ // process a local declaration. These can show up in the output of
+ // -fdebug-unparse-with-modules, too, so go easy on them.
+ if (currScope().IsModule() &&
+ localName.ToString().find("$") != std::string::npos) {
+ Say(useName, "'%s' is PRIVATE in '%s'"_warn_en_US, MakeOpName(useName),
+ useModuleScope_->GetName().value());
+ } else {
+ Say(useName, "'%s' is PRIVATE in '%s'"_err_en_US, MakeOpName(useName),
+ useModuleScope_->GetName().value());
+ return {};
+ }
}
auto &localSymbol{MakeSymbol(localName)};
DoAddUse(useName, localName, localSymbol, *useSymbol);
diff --git a/flang/test/Semantics/resolve11.f90 b/flang/test/Semantics/resolve11.f90
index db508f062d1d1..39a30b858ebb6 100644
--- a/flang/test/Semantics/resolve11.f90
+++ b/flang/test/Semantics/resolve11.f90
@@ -86,3 +86,17 @@ subroutine s5
use m5, only: foo, fun
print *, fun() ! ok
end
+
+module m6
+ !WARNING: 'foo' is PRIVATE in 'm5'
+ use m5, only: name$with$dollar => foo
+ !ERROR: 'foo' is PRIVATE in 'm5'
+ use m5, only: normal_name => foo
+end
+
+subroutine s6
+ !The special dispensation for USE association of private names to local
+ !aliases with '$' in them only applies to modules.
+ !ERROR: 'foo' is PRIVATE in 'm5'
+ use m5, only: name$with$dollar => foo
+end
|
It is mostly because module files contain folded expression values for initializers in which structure constructors are fully elaborated with default component values, and these themselves can be structure constructors for types that are private elsewhere. Also, generic procedure references will have been resolved to specific procedures, and while the original generic was public, the specific resolution may not be. |
The output of a compilation with the -fdebug-unparse-with-modules option comprises its normal unparsed output along with the regenerated contents of any modules that were required from module files. This is handy for producing stand-alone test cases.
The modules' contents are generated by the same code that writes module files, so they can contain some USE associations to private entities in other modules that are necessary to complete local declarations, usually initializers. Such USE associations to private entities are not flagged as fatal errors when modules are read from module files, but they currently are caught when the output produced by this option is being read back in to the compiler.
Handle this case by softening the error to a warning when one module uses a private entity from another with an alias containing the non-conforming '$' character. (I could have omitted the message altogether, but there are other valid warnings that will occur due to undefined function result variables; further, I didn't want to provide a general hole around the protection of private names.)