`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.
(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().
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.
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.
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.
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.
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.
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.
…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.
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.
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.
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.
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.
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.
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.
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).
... 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.
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.
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.
This patch propagates the acc routine information
to the module file so they can be used by the caller.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158541
Name resolutions defers all resolution and checking of specific procedures
in non-type-bound generic interfaces to the end of the specification part.
This prevents expression analysis of references to generic functions in
specification expressions in interfaces from resolving.
Example (now a new test case in modfile07.f90):
```
module m12
interface generic
module procedure specific
end interface
interface
module subroutine s(a1,a2)
character(*) a1
character(generic(a1)) a2 ! <--
end
end interface
contains
pure integer function specific(x)
character(*), intent(in) :: x
specific = len(x)
end
end
```
The solution is to partially resolve specific procedures as they are
defined for each generic, when they can be resolved, with the final
pass at the end of the specification part to finish up any forward
references and emit the necessary error messages.
Making this fix caused some issues in module file output, which have
all been resolved by making this simplifying change: generics are
now all emitted to module file specification parts as their own
group of declarations at the end of the specification part,
followed only by namelists and COMMON blocks.
Differential Revision: https://reviews.llvm.org/D157346
Distinguish between copyin and copyin with the readonly modifier.
Depends on D157121
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157125
OpenACC and OpenMP directive are
emitted in the module file. Just reorganized the code
so this is well separated and do not pollute the main
Fortran part.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157143
F18 produce a module file with a declaration part. This patch
propagates the OpenACC declare information in the module file along the variable
declaration.
Depends on D157042
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157121
Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=. Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.
Differential Revision: https://reviews.llvm.org/D145107
The ProcInterface structure is used only by ProcEntityDetails; it represents
what a program might have put in parentheses in a procedure-declaration-stmt,
either the name of a procedure interface or a declaration-type-spec.
If a procedure entity has an implicit interface, the function result
type (if any) can be kept in EntityDetails::type_, which already exists
and is currently redundant for ProcEntityDetails symbols.
All that is really needed is a nullable Symbol pointer in ProcEntityDetails
to point to the procedure's explicit interface, when it has one.
Also, catch the case where a procedure has an explicit interface
and a program attempts to also give it a type.
Differential Revision: https://reviews.llvm.org/D140134
Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed
later by a corresponding separate module subprogram definition in a
MODULE PROCEDURE, the copies of the interface's dummy argument and
function result symbols that populate the initial scope of that
MODULE PROCEDURE need to have any symbol references in their types
or bounds adjusted to point to their new counterparts.
Differential Revision: https://reviews.llvm.org/D139200
Module files for submodules should not contain PRIVATE attributes,
since everything in them is local to the parent module and
accessible to all descendant submodules.
Differential Revision: https://reviews.llvm.org/D139160
When a submodule defines a module procedure whose interface was declared
in an ancestor (sub)module, don't repeat the definition of that interface
in the submodule's *.mod file output.
Differential Revision: https://reviews.llvm.org/D139132
Rework some recent changes to the ENUM_CLASS() macro so that
all of the construction of enumerator-to-name string mapping
data structures is again performed at compilation time.
Differential Revision: https://reviews.llvm.org/D137859
When a symbol from the enclosing scope is necessary to declare
a procedure or procedure pointer dummy argument or function result
for a procedure interface, note it in the collection of symbols to
be imported when scanning that interface.
Differential Revision: https://reviews.llvm.org/D132683
When a particular module name has been brought into a compilation
as an intrinsic module via USE,INTRINSIC, perhaps indirectly via
an enclosing USE statement, f18 will resolve later USE statements
to it unless they are USE,NON_INTRINSIC. This is not entirely
correct -- a bare USE statement for a module name that happens to
match that of an intrinsic module should still search the search
paths for a non-intrinsic module file of the same name.
Differential Revision: https://reviews.llvm.org/D132163
Defined generic procedure interfaces are allowed to shadow non-generic
procedures of the same name in the same scope (whether or not
that non-generic procedure is a specific procedure of the generic).
When making a copy of a generic interface symbol so that it can
be locally modified or be merged with another generic, don't forget
about the homonymous non-generic procedure that it might shadow.
Differential Revision: https://reviews.llvm.org/D131103
There's a few (3) cases where Fortran allows two distinct symbols to have
the same name in the same scope. Module file output copes with only two of
them. The third involves a separate module procedure that isn't separate:
both the procedure and its declared interface appear in the same (sub)module.
Fix to ensure that the interface is included in the module file output, so
that the module file reader doesn't suffer a bogus error about a "separate
module procedure without an interface".
Differential Revision: https://reviews.llvm.org/D127784
In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on their USE statements. And
ensure that the current working directory (".") cannot override the intrinsic
module search path when trying to locate an intrinsic module.
Differential Revision: https://reviews.llvm.org/D127019
When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modules.
Differential Revision: https://reviews.llvm.org/D126140
Semantics now needs to preserve the parse trees from module files,
in case they contain parameterized derived type definitions with
component initializers that may require re-analysis during PDT
instantiation. Save them in the SemanticsContext.
Differential Revision: https://reviews.llvm.org/D124467
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,
type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type
To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.
This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.
Differential Revision: https://reviews.llvm.org/D123728
The information about OpenMP/OpenACC declarative directives in modules
should be carried in export mod files. This supports export OpenMP
Threadprivate directive and import OpenMP declarative directives.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D120396
Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
