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
When a FUNCTION statement has both an explicit type in its prefix
and a RESULT clause in its suffix, semantics crashes due to the
redundant type; emit a nice error message instead.
Differential Revision: https://reviews.llvm.org/D134504
A generic-spec can appear on a module accessibility control statement
even if it has not been declared as a generic interface, because there's
nothing else that it could be.
While here, simplify the parse tree and parser for AccessId, since
one of its alternatives is ambiguous with the other.
Differential Revision: https://reviews.llvm.org/D134471
Any symbol in a module file will have been already shamed with
portability warnings when the module was compiled, so don't pile
on when compiling other program units that use the module.
This also silences warnings about some symbols whose names were
created or extended by the compiler to avoid clashes.
Differential Revision: https://reviews.llvm.org/D134455
When an explicit MODULE procedure is defined in the same (sub)module
as its interface, and the interface was defined in a generic
interface of the same name, bogus errors about symbols already
having been defined will ensue. Cleaning up this aspect of name
resolution and symbol table management requires marking the
place-holding SubprogramNameDetails symbols of explicit MODULE
subprograms as such, ensuring that that attribute is not inherited
if the SubprogramNameDetails symbol is recycled as a SubprogramDetails,
and gathering some code that should have been common between
BeginSubprogram() and BeginMpSubprogram() together in one
new routine.
Differential Revision: https://reviews.llvm.org/D134446
Attributes like PURE, ELEMENTAL, &c. are specified on the interface of
a separate module procedure, so when the MODULE PROCEDURE is defined in
a submodule, it must acquire those attributes from the interface.
Differential Revision: https://reviews.llvm.org/D134403
The code snippet
module m
interface
module subroutine specific
end subroutine
end interface
interface generic
module procedure specific
end interface
end module
elicits a bogus semantic error about "specific" not being an acceptable
module procedure for the generic interface; fix.
Differential Revision: https://reviews.llvm.org/D134402
We apply special symbol table scoping to top-level subroutine
and function names that have interoperable binding names, so
that it's possible to define the same subroutine/function name
more than once at the top level so long as their binding names
are distinct. But we don't use those scoping techniques for
ENTRY statement symbols with interoperable binding names,
which can lead to bogus semantic errors when the same ENTRY
name is defined multiple times with distinct binding names.
Differential Revision: https://reviews.llvm.org/D134401
There's code in name resolution that handles resolution of references
that appear in the definitions of derived types -- it checks for
existing components in the type being defined, as well as for
non-parent components in its ancestors. Special case code prevents
resolution of a name to the symbol of a procedure binding. This
code needs to be extended so that names of generic procedures
are similarly prevented from shadowing symbols in the scope around
the type.
Differential Revision: https://reviews.llvm.org/D134398
A specific procedure in the list of specific procedures associated with
a generic interface needs to be a symbol that is not inadvertently
resolved to its ultimate symbol in another module when it is also
shadowed by a generic interface of the same name.
Differential Revision: https://reviews.llvm.org/D132686
When, due to one or more USE associations, possibly with renaming,
a symbol conflicts with another of the same name in the same scope,
don't raise an error if both symbols resolve to the same intrinsic
procedure or to the same non-generic external procedure interface --
the usage is unambiguous and safe, and (14.2.2 p8) standard.
(Generic interfaces already work by way of combining their sets of
specific procedures.)
Differential Revision: https://reviews.llvm.org/D132682
A construct entity of an ASSOCIATE or SELECT TYPE construct
should be acceptable as an index variable of a concurrent-header in
a FORALL or DO CONCURRENT, so long as it also satisfies other
requirements.
Differential Revision: https://reviews.llvm.org/D132681
Procedure bindings with explicit interfaces don't work when the
interface is shadowed by a generic interface of the same name,
and can produce spurious semantic error messages. Extend the
characterization and checking code for such things, and the utility
functionns on which they depend, to dig through generics when they
occlude interface-defining subprograms. This is done on demand in
checking code, not once during name resolution, because the
procedures in question may also be forward-referenced.
Differential Revision: https://reviews.llvm.org/D131105
diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h
index e79f8ab6503e..0b03bf06eb73 100644
--- a/flang/include/flang/Semantics/symbol.h
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
Inaccessible components -- those declared PRIVATE in another module -- should
be allowed to be redeclared in extended types, and should be ignored if
they appear as keywords in structure constructors.
Differential Revision: https://reviews.llvm.org/D131102
The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or inner
subprogram. Technically, the use of a name in a BLOCK construct
that is not declared therein is considered in the Fortran standard
to also be a form of host association, and this matters when doing
error checking on DATA statements.
Differential Revision: https://reviews.llvm.org/D130388
A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.
Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.
Differential Revision: https://reviews.llvm.org/D130375
Fortran permits forward references to derived types in contexts that don't
require knowledge of the derived type definition for semantic analysis,
such as in the declaration of a pointer or allocatable variable or component.
But when the forward-referenced derived type is used later for a component
reference, it is possible for the DerivedTypeSpec in he base variable or component
declaration to still have a null scope pointer even if the type has been defined,
since DerivedTypeSpec and TypeSpec objects are created in scopes of use
rather than in scopes of definition. The fix is to call
DerivedTypeSpec::Instantiate() in the name resolution of each component
name so that the scope gets filled in if it is still null.
Differential Revision: https://reviews.llvm.org/D129681
Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with a type-declaration-stmt with a POINTER attribute. In this
case, e.g. "real, external, pointer :: p => null()" the initializer
is required to be a null-init. The parse tree traversal in name
resolution would visit the null-init if the symbol were an object
pointer only, leading to a crash in the case of a procedure pointer.
That explanation of the bug is longer than the fix. In short,
ensure that a null-init in an entity-decl is visited for both
species of pointers.
Differential Revision: https://reviews.llvm.org/D129676
Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics. Use the
new class for all target queries, including derived type component layout
modeling.
Future work will initialize this class with target information
provided or forwarded by the drivers, and use it to fold layout-dependent
intrinsic functions like TRANSFER().
Differential Revision: https://reviews.llvm.org/D129018
Updates: Attempts to work around build issues on Windows.
When a submodule appears in a source file and the compiler can't find the
named ancestor module (and submodule, if one appears), crashes may occur
later due to the absence of a scope. For better resilience, a dummy
ancestral scope should be generated within which the submodule scope
can be created.
Differential Revision: https://reviews.llvm.org/D128760
As Fortran 2018 8.6.4(1), the BIND statement specifies the BIND attribute
for a list of variables and common blocks.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D127120
If BIND(C) appears on an internal procedure, it must have a null binding
label, i.e. BIND(C,NAME="").
Also address conflicts with D127725 which was merged during development.
Differential Revision: https://reviews.llvm.org/D128676
As Fortran 2018 C1520, if proc-language-binding-spec with NAME= is
specified, then proc-decl-list shall contain exactly one proc-decl,
which shall neither have the POINTER attribute nor be a dummy procedure.
Add this check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D127725
As Fortran 2018 C802 and C873, if bind name is specified, there can only
be only one entity. The check for common block is missed before. As
Fortran 2018 8.5.5 point 2, the bind name is one identifier, which is
unique. That is, one entity can not have multiple bind names. Also add
this check.
Reviewed By: klausler, Jean Perier
Differential Revision: https://reviews.llvm.org/D126961
Handle the case of a non-generic procedure that is USE associated
into a scope that has a generic interface of the same name with an
appropriate error rather than crashing.
Differential Revision: https://reviews.llvm.org/D127429
As Fortran 2018 R874, common block object must be one variable name, which
cannot be one named constant. Add this check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126762
When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need to search
the outer generic interfaces as well as the inner ones, but only after
the inner ones have failed to produce a specific procedure that matches
a given set of actual arguments. This means that it is possible for
a specific procedure of a generic interface of an inner scope to override
a conflicting specific procedure of a generic interface of an outer
scope.
Also cope with forward references to derived types when a generic
interface is also in scope.
Fixes LLVM bug https://github.com/llvm/llvm-project/issues/55240 and
LLVM bug https://github.com/llvm/llvm-project/issues/55300.
Differential Revision: https://reviews.llvm.org/D126587
