Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols, including implicitly typed
names from NAMELIST groups and specification expressions in module subprograms,
have been created in its scope.
Fixes https://github.com/llvm/llvm-project/issues/62598.
Differential Revision: https://reviews.llvm.org/D150307
Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148254
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some other compilers) emit a portability
warning when the names all resolve to the same symbol.
Differential Revision: https://reviews.llvm.org/D147388
Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly during name resolution. This allows us to
catch attempts to attach explicit SAVE attributes to anything
that can't have one (constraints C859, C860).
Also delete `IsSave()`, whose few remaining uses were changed to the
more general `IsSaved()` predicate that seems more correct for
those uses, returning true for both explicit and implied SAVE
attributes.
Differential Revision: https://reviews.llvm.org/D146579
Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.
Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.
Differential Revision: https://reviews.llvm.org/D146576
As the new test here shows by failing with the current compiler with
a bogus error message about indistinguishable specific procedures in
a generic interface, name resolution needs to take care to not
copy a USE-associated generic into the current scope for extension
when the USE association is actually into an enclosing scope.
Differential Revision: https://reviews.llvm.org/D145750
Non-DEFERRED procedure binding checking can't blindly accept
all procedures defined in modules -- they can't be ABSTRACT
interfaces. And GetUltimate() must be used rather than
FindSubprogram(); the latter will resolve to a procedure's
interface in the case of "procedure(interface) :: external",
not "external".
Differential Revision: https://reviews.llvm.org/D145749
As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON blocks from specification expressions
before an explicit type-declaration-stmt appears for those variables
under IMPLICIT NONE, so long as those variables are later explicitly typed
with the types that regular implicit typing rules would have given them
(usually default INTEGER).
F18 implemented this extension for dummy arguments, but not variables in
COMMON blocks. Extend the extension to also accept variables in COMMON.
Differential Revision: https://reviews.llvm.org/D145743
Currently, the selector of a construct entity (e.g., ASSOCIATE(x=>a(1:20)))
is inheriting the CONTIGUOUS attribute from its associated variable
even if it has subscripts that make it noncontiguous (a(1:20:2)).
Add construct entities to the dynamic contiguity predicate instead.
Differential Revision: https://reviews.llvm.org/D145114
A BLOCK construct may not contain a statement function definition;
but it may of course contain an assignment statement with an array
element on its left-hand side that looks like a statement function
definition. These misparsed statement functions are converted
into assignment statements during semantics once it is clear what
they are. Move the C1107 check for a statement function definition
in a block construct into declaration checking, which is where it
probably should have been in the first place anyway.
Differential Revision: https://reviews.llvm.org/D145112
A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor type unless that inherited
symbol is also a generic TBP. Since generic names can be things like
"ASSIGNMENT(=)", name resolution doesn't use OkToAddComponent() for
generic TBPs, which would have caught this error as it does for other
symbols in derived types, so it must be special-cased.
Differential Revision: https://reviews.llvm.org/D145109
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
Fix USE rename when use-name and local-name are the same.
Previously, the associated symbol was being removed from scope.
Operator rename implementation needed no change, because, as it
doesn't call AddUseRename(), symbol erasure is skipped.
Fixes#60223
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D143933
A BIND(C) attribute statement or type-declaration-stmt attribute, just
like most attributes, can only appear once. Name resolution was excluding
the BIND(C) attribute from its check for duplicated attributes, but I
don't see a reason that remains to do so.
Differential Revision: https://reviews.llvm.org/D143834
The recent code that uses an iterative rather than recursive walk
over the parse tree when processing expressions needs to allow for
the rare case in which an intrinsic operator (e.g., +) is extended
by a generic interface in the program.
Differential Revision: https://reviews.llvm.org/D143818
Don't call CheckCommonBlockDerivedType() recursively if the
derived type symbol is the same symbol that is already being
processed. This can happen when a component is a pointer of the
same type as its parent component, for instance.
Fixes#60230
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D143211
When a USE of a module precedes its definition in the same source
file, ensure that the module is processed by name resolution before
the USE statement. This prevents the risk of the USE statement using
an obsolete module file that is later overwritten during the same
compilation.
Differential Revision: https://reviews.llvm.org/D143799
f18 implements BLOCK scoping for construct names, like most but not all Fortran
compilers, but in the 2018 standard such names are defined to be local identifiers
whose scope is the inclusive scope -- i.e., the subprogram or main program.
Detect usage that depends on this extension and emit a portability warning.
Differential Revision: https://reviews.llvm.org/D143776
When a descriptor inquiry or inquiry function's result is
not constant and is known to be impossible to correctly determine
at runtime, raise an error. For example, LEN(X) when X is
a local allocatable variable with deferred length.
Differential Revision: https://reviews.llvm.org/D142759
Emit an error message when the right-hand side expression of a statement function
definition cannot be converted to the type of the statement function.
Differential Revision: https://reviews.llvm.org/D142745
ENUMERATOR declarations are checking for conflicts between new
enumerator names and names in both the local scope and scopes
that contain it. ENUMERATOR declarations belong to the local
scope and so only a conflict with a name therein is an error.
(In short, use FindInScope rather than FindSymbol.)
Differential Revision: https://reviews.llvm.org/D142773
f18 current ignores attempts to initialize (with =expr) things
that are not objects, or allows meaningless initializations of
things that have mistakenly been promoted to be objects.
Fix by refusing to promote to objects names that have any
attributes that cannot be applied to objects, and then catch
data initializations of symbols that are not objects.
Differential Revision: https://reviews.llvm.org/D142766
A function in a defined operator generic interface will syntactically
have one or two arguments. If a defined operator includes a specific
function with 0 or more than 2 dummy arguments, there's no way that it
could be invoked by way of the interface. Emit a warning.
Differential Revision: https://reviews.llvm.org/D142762
A dummy argument that appears only in ENTRY statements may
not be used in the executable part prior to its first ENTRY
statement.
Differential Revision: https://reviews.llvm.org/D142758
In an error recovery situation, the name resolution code for a
SELECT TYPE statement must check the presence of an optional
expression before calling GetType() upon it.
Differential Revision: https://reviews.llvm.org/D140153
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
Most attributes apply to only object or only procedure entities,
and attempts to apply them to other kinds of symbol table entries
are caught in name resolution when ConvertToObjectEntity() or
ConvertToProcEntity() fails. However, the POINTER attribute can
be applied to both, and name resolution can't perform that conversion
yet, and as a result we don't catch many kinds of silly errors.
Fix by ensuring that the symbol is of a type that could eventually
become an object or procedure entity if it is not one already.
Differential Revision: https://reviews.llvm.org/D140137
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
Check most of the requiremens of constraint C1577 for statement functions.
The restrictions that prevent recursion are hard errors; the others seem
to be benign legacies and are caught as portability warnings.
Differential Revision: https://reviews.llvm.org/D139136
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
Type-bound generics like operator(+) and assignment(=) need to not be
PRIVATE if they are used outside the module in which they are declared.
Differential Revision: https://reviews.llvm.org/D139123
When checking the specific procedures of a generic interface for a
match against a given set of actual arguments, be sure to not match
a function against a subroutine call or vice versa. (We generally
catch and warn about attempts to declare mixed interfaces, but they
are usually conforming and can be inadvertently created when generics
are merged due to USE and host association.)
Differential Revision: https://reviews.llvm.org/D139059
12.6.3p5 requires an I/O data list item to have a defined I/O procedure
if it is polymorphic. (We could defer this checking to the runtime,
but no other Fortran compiler does so, and we would also have to be
able to catch the case of an allocatable or pointer direct component
in the absence of a defined I/O subroutine.)
Also includes a patch to name resolution that ensures that a
SELECT TYPE construct entity is polymorphic in the domain of a
CLASS IS guard.
Also ensures that non-defined I/O of types with PRIVATE components
is caught.
Differential Revision: https://reviews.llvm.org/D139050
A NULL() pointer is generally not a valid expression (as opposed to
a variable) apart from some initialization contexts and some actual
arguments.
Differential Revision: https://reviews.llvm.org/D139047
The infrastructure in semantics that is used to check that the
left-hand sides of normal assignment statements are really definable
variables was not being used to check whether the LHSs of pointer assignments
are modifiable, and so most cases of unmodifiable pointers are left
undiagnosed. Rework the semantics checking for pointer assignments,
NULLIFY statements, pointer dummy arguments, &c. so that cases of
unmodifiable pointers are properly caught. This has been done
by extracting all the various definability checking code that has
been implemented for different contexts in Fortran into one new
facility.
The new consolidated definability checking code returns messages
meant to be attached as "because: " explanations to context-dependent
errors like "left-hand side of assignment is not definable".
These new error message texts and their attached explanations
affect many existing tests, which have been updated. The testing
infrastructure was extended by another patch to properly compare
warnings and explanatory messages, which had been ignored until
recently.
Differential Revision: https://reviews.llvm.org/D136979
There are some exceptional cases where the compiler permits association of
procedure pointers or dummy arguments with slightly incompatible procedure
targets, but they should not override any incompatibilty of function
result types.
(Includes a second fix to resolve the original motivating test failure, in
which a COMPLEX intrinsic function was getting its result kind divided by
two due to an implicit C++ conversion of the kind to a "*kind" parse tree
node, and those legacy "COMPLEX*size" type designators' values are twice
the type kind value.)
Differential Revision: https://reviews.llvm.org/D136964
A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.
Differential Revision: https://reviews.llvm.org/D136991
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
Broaden the check for misuse of ABSTRACT procedure interfaces by
doing it in expression analysis rather than name resolution so that
cases like pointer assignment targets and actual arguments are also
diagnosed as errors.
Differential Revision: https://reviews.llvm.org/D136971
Semantics checks C702, which disallows deferred type parameters for
any entity that is neither an allocatable nor a pointer, only during
name resolution of type declaration statements. This check needs to
be broader, since Fortran entities can have their types specified in
other ways. Rewrite the check and move it to the general declaration
checking pass.
Differential Revision: https://reviews.llvm.org/D136970
When a derived type has a procedure pointer component with no interface,
we can't do a lot of checking on its call sites, but we can at least require
that the same procedure pointer component be used consistently as either
a function or as a subroutine, but not both.
Differential Revision: https://reviews.llvm.org/D136905
Fortran famously allows a generic interface definition to share a
scope with a procedure or derived type of the same name. When that
shadowed name is accessed via host or USE association, but is also
defined by an interface in the generic, then name resolution needs
to fix up the representation of the shadowing so that the new interface
definition is seen as the shadowed symbol -- the host or USE associated
name is not material to the situation. See the new test case for
particular examples.
Differential Revision: https://reviews.llvm.org/D136891
Name resolution was mishandling cases of generic interfaces and specific procedures
(sometimes complicatd by use of the same name for each) when the specific procedure
was accessed by means of host association; only the scope of the generic interface
definition was searched for the specific procedure. Also search enclosing scopes
in the usual way.
Differential Revision: https://reviews.llvm.org/D135213
When a generic interface in a module shadows a procedure of the same name that
has been brought into scope via USE association, ensure that that USE association is
not lost when the module file is written.
Differential Revision: https://reviews.llvm.org/D135207
f18 emits an error message when the same name is used in a scope
for both a procedure and a generic interface, and the procedure is
not a specific procedure of the generic interface. It may be
questionable usage, and not portable, but it does not appear to
be non-conforming by a strict reading of the standard, and many
popular Fortran compilers accept it.
Differential Revision: https://reviews.llvm.org/D135205
