Call GetUltimate() before checking a user-defined derived type I/O specific
procedure so that the checks work on a USE-associated procedure. And
require their character arguments to have the default CHARACTER kind.
Differential Revision: https://reviews.llvm.org/D147386
A CONTIGUOUS entity must be an array pointer, assumed-shape dummy array,
or assumed-rank dummy argument (C752, C830). As currently implemented,
f18 only implements the array requirement if the entity is a pointer.
Combine these checks and start issuing citations to scalars.
Differential Revision: https://reviews.llvm.org/D146588
C721 says that a type parameter value of '*' is permitted in the type-spec
for a named constant; C795 says that such type parameters are allowed
in type-specs only for a few kinds of things, not including named
constants. The interpretation seems to depend on context, with C721
applying to intrinsic types (i.e., character) and C795 applying only
to derived types.
Differential Revision: https://reviews.llvm.org/D146586
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
A PRIVATE procedure binding in a derived type extension may not
be an override of a PUBLIC procedure binding. Declaration checking
for this case was working only in the presence of an explicit
PUBLIC accessibility attribute, when it should be checking for the
absence of a PRIVATE accessibility attribute.
Differential Revision: https://reviews.llvm.org/D146577
When multiple scopes in a compilation define interfaces (explicit
or implicit) for an external procedure, warn when those interfaces
are inconsistent.
Differential Revision: https://reviews.llvm.org/D146574
Procedures with the EXTERNAL attribute (explicit or implied) are
not permitted to be ALLOCATABLE or be arrays if their interfaces
are implicit.
Differential Revision: https://reviews.llvm.org/D146572
The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindings. It also works
for explicit INTERFACE blocks and GENERIC statements that define
UDDIO subroutines in the same scope as the definition of the derived type,
so long as the specific procedures in those bindings are module procedures
or external procedures.
For non-type-bound UDDTIO specific procedures that are dummy procedures,
thunks of inner procedures, or procedure pointers, or that are defined with
interfaces or GENERIC outside the scope of the definition of the derived
type, a new runtime I/O API is needed so that lowering can generate
a call that supplies the appropriate procedure as well as the defined
type instance.
This patch specifies and implements this new runtime API and provides
utility routines for lowering to use to determine whether it should be
called for any particular OutputItem or InputItem in the parse tree.
Differential Revision: https://reviews.llvm.org/D146571
Some Fortran compilers allow kinds of LOGICAL other than C_BOOL
for the types of dummy arguments to interoperable (BIND(C))
procedures. As any kind of LOGICAL can be converted to any
other without loss of information, this seems to be a useful
unambiguous extension that is attested in real codes; accept it
for scalars with a portability warning.
Differential Revision: https://reviews.llvm.org/D145968
Declaration checking in semantics was only examining symbols with
explicit BIND(C) attributes; extend it to also check dummy arguments
to such procedures.
Differential Revision: https://reviews.llvm.org/D145746
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
The compiler currently ignores attributes for PASS dummy arguments that
are incompatible between a type-bound procedure in an extended type and
the binding of the same name that it overrides in an ancestor type,
if any. Strengthen this checking so that discrepancies between attributes
and intents are caught, and add some tests.
Differential Revision: https://reviews.llvm.org/D145110
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
Fortran doesn't allow a BIND(C) variable or a component of a BIND(C)
type to be an array with no elements.
Differential Revision: https://reviews.llvm.org/D145106
When a procedure binding in a derived type has PRIVATE accessibility,
it may not be an override of a type-bound procedure that is accessible.
Differential Revision: https://reviews.llvm.org/D145104
Generic interfaces are not permitted to have intrinsic procedures or
statement functions as specific procedures.
Differential Revision: https://reviews.llvm.org/D145103
A procedure defined in an ABSTRACT INTERFACE may not appear as
a specific procedure in a generic interface.
Differential Revision: https://reviews.llvm.org/D145102
The Fortran 2018 standard, perhaps as an attempt to prevent ambiguity
in older compilers, requires that a statement function appear in an
explicit type declaration statement if its name is also accessible
from a host scope. F18 processes the specification parts of inner
procedures first, so we don't need this requirement to prevent
ambiguity, and can only really check it retrospectively after name
resolution. Emit a portability warning when appropriate.
Differential Revision: https://reviews.llvm.org/D145100
Every component of a BIND(C) interoperable derived type must have an
interoperable type. Semantics was checking components with derived types,
but not components with intrinsic types.
Differential Revision: https://reviews.llvm.org/D143832
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
Semantics crashes when emitting runtime derived type information tables
for a type that has user-defined I/O procedures declared outside the
type with explicit INTERFACE blocks (as opposed to a GENERIC binding
within the type). This is due to the runtime table constructor
adding a table entry for each specific procedure of any explicit interface
of the right kind (e.g., READ(UNFORMATTED)) that it found, rather than
just the ones that pertain to the derived type in question. But
semantics also wasn't checking such interfaces for distinguishable
specific procedures, either.
Clean these up, improve the spelling of defined I/O procedure kinds
in error messages ("read(formatted)" rather than "READFORMATTED"),
and make error messages stemming from macro expansions only have
one "error:" prefix on the original message so that a new test
would work.
Differential Revision: https://reviews.llvm.org/D142769
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 subroutine that implements a defined assignment cannot have
a dummy argument for its second operand (the RHS of the assignment)
with the POINTER or ALLOCATABLE attributes, since the RHS of
an assignment is always an expression. This problem is flagged
as a fatal error in other compilers, so let's make it fatal here
as well.
Differential Revision: https://reviews.llvm.org/D142752
As Fortran 2018 C1553, if with BIND(C), the function result shall be an
interoperable scalar variable. As Fortran 2018 18.3.4(1), the
interoperable scalar variable is not a coarray, has neither the
ALLOCATABLE nor the POINTER attribute, and if it is of type character its
length is not assumed or declared by an expression that is not a constant
expression.
As Fortran 2018 18.3.1(1), if the type is character, the length type
parameter is interoperable if and only if its value is one.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137254
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
When a function has an implicit interface its result type may
not have a deferred type parameter.
Differential Revision: https://reviews.llvm.org/D140132
An assumed-size dummy array argument with INTENT(OUT) can't have a type
that might require any runtime (re)initialization, since the size of the
array is not known.
Differential Revision: https://reviews.llvm.org/D139149
Modules, submodules, main programs, and BLOCK DATA subprograms have names
that cannot be used within their scope, so we allow those names to be
used for other entities in the scope. This might not be entirely
conformant with the language standard, so warn about it.
Differential Revision: https://reviews.llvm.org/D139146
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
A recent change moved some checking code from name resolution into
declaration checking, and inadvertently disabled C702 checking for
procedure entities. Fix.
Differential Revision: https://reviews.llvm.org/D139043
When a scope declares the name and perhaps some characteristics of
an external subprogram using any of the many means that Fortran supplies
for doing such a thing, and that external subprogram's definition is
available, check the local declaration against the external definition.
In particular, if the global definition's interface cannot be called
by means of an implicit interface, ensure that references are via an
explicit and compatible interface.
Further, extend call site checking so that when a local declaration
exists for a known global symbol and the arguments are valid for that
local declaration, the arguments are checked against the global's
interface, just are is already done when no local declaration exists.
Differential Revision: https://reviews.llvm.org/D139042
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
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
Fortran's constraint C721 allows an assumed-length CHARACTER
entity to be declared in a very limited set of circumstances that
does not include an explicit external interface definition.
Differential Revision: https://reviews.llvm.org/D136963
As Fortran 2018 C1546, an elemental procedure shall not have the BIND
attribute.
As 18.3.6, it does not mention that an array with VALUE can be
interoperable. It is not reasonable to pass an array by value when the
array is too large. Forbid it to be consistent with gfortran/ifort.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136420
Fortran strangely allows declarations to appear in procedure interface
definitions when those declarations do not contribute anything to the
characteristics of the procedure; in particular, one may declare local
variables that are neither dummy variables nor function results.
Such declarations "have no effect" on the semantics of the program,
and that should include semantic error checking for things like
special restrictions on PURE procedures.
Differential Revision: https://reviews.llvm.org/D135209
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
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
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
As Fortran 2018 C1806, each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component with
interoperable type.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D131585
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
When a procedure pointer references a function as its interface, don't
apply semantic checks to the specification expressions that appear in
the declaration of the function's result -- this can lead to bogus
error messages as those specification expressions are being examined
out of their proper context.
Differential Revision: https://reviews.llvm.org/D131106
