[flang] Fix crash in module file generation (#123859)

An assertion in module file generation didn't allow for a case that has
arisen in a test; remove it, extend commentary, and add a regression
t

[flang] Fix crash in module file generation (#123859)

An assertion in module file generation didn't allow for a case that has
arisen in a test; remove it, extend commentary, and add a regression
test.

Fixes https://github.com/llvm/llvm-project/issues/123534.

show more ...

[flang] Safer hermetic module file reading (#121002)

When a hermetic module file is read, use a new scope to hold its
dependent modules so that they don't conflict with any modules in the
global s

[flang] Safer hermetic module file reading (#121002)

When a hermetic module file is read, use a new scope to hold its
dependent modules so that they don't conflict with any modules in the
global scope.

show more ...

[flang] Improve module file error message wording (#122787)

Instead of "Cannot read ...", distinguish true errors in finding and
parsing module files from problems with unexpected hash codes by usi

[flang] Improve module file error message wording (#122787)

Instead of "Cannot read ...", distinguish true errors in finding and
parsing module files from problems with unexpected hash codes by using
"Cannot parse" or "Cannot use" wording as appropriate.

show more ...

[flang] Prevent errors from being suppressed (#114420)

`ModFileReader::Say()` flags all messages as errors, but Flang was
mistakenly suppressing two errors when the `-w` flag was used, as they
wer

[flang] Prevent errors from being suppressed (#114420)

`ModFileReader::Say()` flags all messages as errors, but Flang was
mistakenly suppressing two errors when the `-w` flag was used, as they
were incorrectly conditioned to warning suppression. This fix ensures
that errors are reported regardless of the `-w` flag.

This commit also replaces two uses of `_warn_en_US` with `_err_en_US` to
prevent potential confusion in the future.

show more ...

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)

Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.

The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.

Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.

To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().

show more ...

[flang] Fix edge case regression (#109350)

A recent fix to the emission of derived type names to module files
exposed a regression in the case of a derived type that (1) has the same
name as a gen

[flang] Fix edge case regression (#109350)

A recent fix to the emission of derived type names to module files
exposed a regression in the case of a derived type that (1) has the same
name as a generic procedure interface and (2) has undergone renaming
through USE association before (3) being used in a declaration
significant to a module procedure interface. Fix.

show more ...

[flang] Detect use-before-decl errors on type parameters (#99947)

Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such refe

[flang] Detect use-before-decl errors on type parameters (#99947)

Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such references would
resolve to symbols in the enclosing scope.)

This change causes the symbols for the type parameters to be created
when the TYPE statement is processed in name resolution. They are
TypeParamDetails symbols with no KIND/LEN attribute set, and they shadow
any symbols of the same name in the enclosing scope.

When the type parameter declarations are processed, the KIND/LEN
attributes are set. Any earlier reference to a type parameter with no
KIND/LEN attribute elicits an error.

Some members of TypeParamDetails have been retyped &/or renamed.

show more ...

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their mod

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their module files with USE statements and special comments with hash
codes in them to ensure that those USE statements resolve to the same
modules that were used to build the module when its module file was
generated.

This scheme prevents unchecked module file growth in large applications
by not emitting USE-associated symbols redundantly. This problem can be
especially bad when derived type definitions must be repeated in the
module files of their clients, and the clients of those modules, and so
on. However, this scheme has the disadvantage that clients of modules
must be compiled with dependent modules in the module search path.

This new -fhermetic-module-files option causes module file output to be
free of dependences on any non-intrinsic module files; dependent modules
are instead emitted as part of the module file, rather than being
USE-associated. It is intended for top level library module files that
are shipped with binary libraries when it is not convenient to collect
and ship their dependent module files as well.

Fixes https://github.com/llvm/llvm-project/issues/97398.

show more ...

[flang] Fix bug introduced by PR#93106 (#93326)

https://github.com/llvm/llvm-project/pull/93106 introduced some
necessary fixes to module file generation, but has also caused a
regression. The mod

[flang] Fix bug introduced by PR#93106 (#93326)

https://github.com/llvm/llvm-project/pull/93106 introduced some
necessary fixes to module file generation, but has also caused a
regression. The module file output can include bogus attempts to
USE-associate symbols local to derived type scopes, like components and
bindings. Fix, and extend a test.

show more ...

[flang] Better renaming in module files (#93106)

When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for

[flang] Better renaming in module files (#93106)

When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for it -- either with a name that is already available via USE
association with renaming, or by means of a new private USE association,
possibly with renaming to avoid a clash.

Module file output was dealing properly with names of derived types, but
wasn't accounting for symbols that appear in expressions other than
initializations. This was specifically a problem with an application
module that had a call to a NOPASS type-bound procedure in an array
bound specification expression, which semantics had resolved to the name
of a private module function.

This patch implements renaming, when necessary, for all symbols
appearing in expressions and type names, and replaces the previous
implementation of derived type renaming. It also gets a little smarter
about avoiding the creation of compiler-generated names when a name from
another module has been brought into scope already by means of USE
association with renaming.

show more ...

[flang] New -fdebug-unparse-with-modules option (#91660)

This option is a compilation action that parses a source file and
performs semantic analysis on it, like the existing -fdebug-unparse
optio

[flang] New -fdebug-unparse-with-modules option (#91660)

This option is a compilation action that parses a source file and
performs semantic analysis on it, like the existing -fdebug-unparse
option does. Its output, however, is preceded by the effective contents
of all of the non-intrinsic modules on which it depends but does not
define, transitively preceded by the closure of all of those modules'
dependencies.

The output from this option is therefore the analyzed parse tree for a
source file encapsulated with all of its non-intrinsic module
dependencies. This output may be useful for extracting code from large
applications for use as an attachment to a bug report, or as input to a
test case reduction tool for problem isolation.

show more ...

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a tr

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.

show more ...

[flang] Fix CHECK() crash in module file generator (#90234)

A sanity CHECK() in mod-file.cpp needs to allow for USE association of a
derived type that has the same name as a locally defined generic

[flang] Fix CHECK() crash in module file generator (#90234)

A sanity CHECK() in mod-file.cpp needs to allow for USE association of a
derived type that has the same name as a locally defined generic
interface.

Fixes https://github.com/llvm/llvm-project/issues/90192.

show more ...

[flang] Clean up ISO_FORTRAN_ENV, fix NUMERIC_STORAGE_SIZE (#87566)

Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculat

[flang] Clean up ISO_FORTRAN_ENV, fix NUMERIC_STORAGE_SIZE (#87566)

Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculation of its
value is deferred until it is needed so that the effects of
-fdefault-integer-8 or -fdefault-real-8 are reflected. Emit a warning
when NUMERIC_STORAGE_SIZE is used from the module file and the default
integer and real sizes do not match.

Fixes https://github.com/llvm/llvm-project/issues/87476.

show more ...

[flang] Support multiple distinct module files with same name in one … (#84838)

…compilation

Allow multiple module files with the same module name to exist in one
compilation; distinct modules a

[flang] Support multiple distinct module files with same name in one … (#84838)

…compilation

Allow multiple module files with the same module name to exist in one
compilation; distinct modules are distinguished by their hashes.

show more ...

[flang] Emit "raw" name for procedure interface in module file (#83915)

Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in

[flang] Emit "raw" name for procedure interface in module file (#83915)

Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in symbol table
entries with ProcEntityDetails. The raw symbol of the interface needs to
be the one used for emitting procedure symbols to module files.

Fixes https://github.com/llvm/llvm-project/issues/83836.

show more ...

[flang] Use module file hashes for more checking and disambiguation (#80354)

f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the

[flang] Use module file hashes for more checking and disambiguation (#80354)

f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the following contents.
This hash is currently used only to protect module files against
corruption and truncation.

Extend the use of these hashes to catch or avoid some error cases. When
one module file depends upon another, note its hash in additional module
file header comments. This allows the compiler to detect when the module
dependency is on a module file that has been updated. Further, it allows
the compiler to find the right module file dependency when the same
module file name appears in multiple directories on the module search
path.

The order in which module files are written, when multiple modules
appear in a source file, is such that every dependency is written before
the module(s) that depend upon it, so that their hashes are known.

A warning is emitted when a module file is not the first hit on the
module file search path.

Further work is needed to add a compiler option that emits (larger)
stand-alone module files that incorporate copies of their dependencies
rather than relying on search paths. This will be desirable for
application libraries that want to ship only "top-level" module files
without needing to include their dependencies.

Another future work item would be to admit multiple modules in the same
compilation with the same name if they have distinct hashes.

show more ...

[flang] Turn "error" cases into warning for "indistinguishable" specific procedures (#79621)

When a generic procedure interface, either declared or the result of
merging two use-associated gene

[flang] Turn "error" cases into warning for "indistinguishable" specific procedures (#79621)

When a generic procedure interface, either declared or the result of
merging two use-associated generics, has two specific procedures
that are not distinguishable according to the rules in F'2023
subclause 15.4.3.4.5, emit a portability warning rather than a
hard error message. The rules in that subclause are not adequate
to detect pairs of specific procedures that admit an ambiguous
reference, as demonstrated by a case that arose in pFUnit. Further,
these distinguishability checks, even if sufficient to the task
of detecting pairs of specifics capable of ambiguous references,
should only apply to pairs where *every* reference would have to
be ambiguous -- and this can and is validated at every reference
anyway. Last, only XLF enforces these incomplete and needless
distinguishability rules -- every other compiler seems to just
check that each procedure reference resolves to exactly one
specific procedure.

If the standard were to complete lose subclause 15.4.3.4.5 and
its related note (C.11.6) -- which admits that the rules are
incomplete! -- and simply require that each generic procedure
reference resolve unambiguously to exactly one specific, nobody
would miss them. This patch changes this compiler to give them
lip service when requested, but they are now otherwise ignored.

show more ...

[flang] Fix module file generation when generic shadows derived type (#78618)

Fortran allows the name of a generic interface to be the same as the
name of a derived type or specific procedure. When

[flang] Fix module file generation when generic shadows derived type (#78618)

Fortran allows the name of a generic interface to be the same as the
name of a derived type or specific procedure. When this happens, it
causes the code in module file generation to miss the symbol of a
derived type when scanning for symbols in initialization expressions
that need to be imported. Fix.

show more ...

[flang] Refine IMPORT processing in module file generation (#77133)

Procedure interfaces emitted to module files are including IMPORT
statements for some symbols that don't need to be imported (bas

[flang] Refine IMPORT processing in module file generation (#77133)

Procedure interfaces emitted to module files are including IMPORT
statements for some symbols that don't need to be imported (base types
and procedure interfaces for components of imported derived types) and
omitting others (procedure interfaces for bindings in locally-defined
derived types that are material to the interface).

show more ...

[flang][openacc] Carry device dependent info for routine in the module file

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the curren

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the current module.

This came up in a test with a derived type component default initializer
of "c_null_ptr", which is replaced with the expression
"__builtin_c_ptr(address=0_8)"; the derived type name "__builtin_c_ptr"
is not available in the current scope, and the module file would fail
semantic analysis when USE'd.

The best solution that I found was to extend module file generation to
detect this case and handle it by inserting the right USE association to
the ultimate derived type symbol, possibly with renaming to a
compiler-created name in the case of a conflict.

To implement this transformation, it was necessary to fix the utility
evaluate::CollectSymbols() to include the derived type symbol from a
structure constructor. This involved extending the expression traversal
framework to visit the derived type spec of a structure constructor.
Extending CollectSymbols() caused a lowering test to fail mysteriously,
so I tracked down the code in PFTBuilder that didn't expect to see a
DerivedTypeDetails symbol and dealt with it there.

show more ...

[flang] Submodule names can clash only with submodule names (#67361)

Name resolution creates symbols for submodules in their parents' scopes.
This can lead to bogus errors about name clashes betwee

[flang] Submodule names can clash only with submodule names (#67361)

Name resolution creates symbols for submodules in their parents' scopes.
This can lead to bogus errors about name clashes between submodule names
and other entities in the parents' scopes.

Create symbols for submodules but do not add them to a scope's
dictionary.

show more ...

[flang] Do not write implicit SAVE attribute into the mod file. (#67215)

If it happens that a symbol has an implicit SAVE attribute,
we have to omit it in the mod file writer. Otherwise it may
vio

[flang] Do not write implicit SAVE attribute into the mod file. (#67215)

If it happens that a symbol has an implicit SAVE attribute,
we have to omit it in the mod file writer. Otherwise it may
violate F202X C862:
The SAVE attribute shall not be specified for... an object that is
in a common block.

show more ...

[flang] Cray pointer in module (#66119)

This patch is to add the support of declaring a Cray pointer in a
module.