Declaration checking catches the error of a COMMON block and a subprogram
definition having the same name, but misses the case of a COMMON block
and an a reference to an external subprogram with an implicit interface.
Fix. Fixes bug https://github.com/llvm/llvm-project/issues/63247.
Differential Revision: https://reviews.llvm.org/D153786
A recent fix to avoid bogus errors with the CONTIGUOUS attribute caused
declaration checking to miss errors with applications of CONTIGUOUS to
names that are not variables. Restore those error messages, and
add tests to ensure that the original problem remains fixed while
the recent regressions have been resolved.
Differential Revision: https://reviews.llvm.org/D151124
Incorrect error messages were issuing for symbol table entries
with the CONTIGUOUS attribute that didn't deserve them, like
host association symbols. Put the CONTIGUOUS check into
CheckObjectEntity().
Differential Revision: https://reviews.llvm.org/D150712
Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
Allow two currently erroneous cases of !DIR$ IGNORE_TKR errors: allocatable
and pointers, and IGNORE_TKR(R) on (other) arguments passed via descriptors.
Downgrade these cases to warnings when they appear in external interfaces,
since their implementations may well be in C. But retain the error status
on these cases for module procedures, since the Fortran implementation
probably can't work.
Differential Revision: https://reviews.llvm.org/D148833
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
TYPE(*) arguments fell through in IS_CONTIGUOUS folding
because they are not Expr<SomeType>. Expose entry point for
symbols in IsContiguous and use that.
The added test revealed that IS_CONTIGUOUS was folded to
false for assumed rank arguments. Fix this: the contiguity of
assumed rank without the CONTIGUOUS argument can only be
verified at runtime.
Differential Revision: https://reviews.llvm.org/D148128
A fairly recent introduction of runtime I/O APIs called OutputDerivedType()
and InputDerivedType() didn't cover NAMELIST I/O's need to access
non-type-bound generic interfaces for user-defined derived type I/O
when those generic interfaces are defined in some scope other than the
one that defines the derived type.
The patch adds a new data structure shared between lowering
and the runtime that can represent all of the cases that can
arise with non-type-bound defined I/O. It can represent
scopes in which non-type-bound defined I/O generic interfaces
are inaccessible, too, due to IMPORT statements.
The data structure is now an operand to OutputDerivedType() and
InputDerivedType() as well as a data member in the NamelistGroup
structure.
Differential Revision: https://reviews.llvm.org/D148257
Many semantic checks for constraints related to PURE subprograms
can be implemented in terms of Semantics' "definable.h" utilities,
slightly expanded. Replace some particular PURE constraint
checks with calls to WhyNotDefinable(), except for cases that
had better specific error messages, and start checking some
missing constraints with DEALLOCATE statements and local
variable declarations.
Differential Revision: https://reviews.llvm.org/D147389
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
