…ion result)
A function can't return a statement function, so an apparent attempt to
define a statement function with the same name as the function's result
must be a misparsed assignment statement.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
As an extension, accept the redundant use of the CONTIGUOUS attribute
when applied to scalars and to simply contiguous objects, with a
portability warning.
The online CUDA Fortran documentation states that a device subprogram
must be a top-level module subprogram, but this has turned out to be an
obsolete constraint. Stop enforcing it.
When a separate module function's definition has a redundant interface
-- it's defined with MODULE FUNCTION, not MODULE PROCEDURE -- the check
for result type equivalence needs to allow for character lengths that
are the results of specification expressions. At present,
identical-looking length specification expression don't compare equal,
since they can refer to distinct dummy argument symbols. Ensure just
that they are both constant or not, and if constant, that the lengths
have the same value.
When a derived type definition is visible by two or more names in the
same scope due to USE renaming, any generic ASSIGNMENT(=) or OPERATOR()
bindings in the type will produce incorrect error messages about
indistinguishable specific procedures. This is due to the use of a
std::vector<> to hold a sequence of symbols and some derived information
for the specific procedures of the generic name. Change to a std::map<>
indexed by the ultimate symbol of each specific so that duplicates
cannot arise.
The change https://github.com/llvm/llvm-project/pull/67361 removed
submodule name symbols from the name dictionaries of their parent
(sub)modules to prevent needless errors about name clashes, but these
symbols still need to be checked for things like excessive length.
F'202X 7.5.2.4 describes conditions under which two derived type
definitions are to be considered equivalent. These rules are already
implemented in Evaluate/type.cpp but not exposed for general use;
rearrange the code a little so that the compatibility checking of
separate module procedure interfaces and explicit definitions can use it
to avoid emitting a bogus error message.
Fixes https://github.com/llvm/llvm-project/issues/67946.
Defining a procedure with a BIND(C, NAME="...") where the binding label
matches the assembly name of a non BIND(C) external procedure in the
same file causes a failure when generating the LLVM IR because of the
assembly symbol name clash.
Prevent this crash with a clearer semantic error.
The warning message about a derived type not having a FINAL subroutine
for a particular object's rank should not issue for an assumed-rank
dummy argument.
Implements compatibility checking for initializers in procedure pointer
declarations. This work exposed some inconsistency in how ELEMENTAL
interfaces were handled and checked, from both unrestricted intrinsic
functions and others, and some refinements needed for function result
compatbility checking; these have also been ironed out. Some new
warnings are now emitted, and this affected a dozen or so tests.
Differential Revision: https://reviews.llvm.org/D159026
Unlike other executable constructs with associating selectors, the
selector of a SELECT RANK construct can have the ALLOCATABLE or POINTER
attribute, and will work as an allocatable or object pointer within
each rank case, so long as there is no RANK(*) case.
Getting this right exposed a correctness risk with the popular
predicate IsAllocatableOrPointer() -- it will be true for procedure
pointers as well as object pointers, and in many contexts, a procedure
pointer should not be acceptable. So this patch adds the new predicate
IsAllocatableOrObjectPointer(), and updates some call sites of the original
function to use the new one.
Differential Revision: https://reviews.llvm.org/D159043
When checking that a module procedure definition is unique, allow for
the possibility that a submodule may contain a module procedure
interface that shadows a module procedure of the same name in its
(sub)module parent. In other words, module procedure definitions
need only be unique in the tree of submodules rooted at the (sub)module
containing the relevant module procedure interface.
Differential Revision: https://reviews.llvm.org/D159033
BIND(C) interoperable pointer descriptors may not be required to be
CONTIGUOUS in procedure interfaces.
(Also fixed erroneous true result from IsDescriptor() predicate for
assumed-size arrays that was exposed by testing.)
Fixes llvm-test-suite/Fortran/gfortran/regression/bind_c_contiguous.f90.
Differential Revision: https://reviews.llvm.org/D157342
At least one other Fortran compiler supports the use of unrestricted intrinsic
functions as specific procedures in generic interfaces, and the usage seems
to be both useful and unambiguous. Support it with a portability warning.
Fixes llvm-test-suite/Fortran/gfortran/regression/pr95500.f90.
Differential Revision: https://reviews.llvm.org/D157333
A semantics check for an assumed-length dummy procedure pointer was
inappropriately part of an "else" clause for a preceding check,
causing it to not be applied in all situations.
Differential Revision: https://reviews.llvm.org/D155975
The check for inappropriate usage of the ASYNCHRONOUS attribute
needed to be moved in declaration checking so that it can catch
attempts to use it on a subroutine.
Differential Revision: https://reviews.llvm.org/D155970
Entities declared with CLASS() must be dummy arguments, allocatables,
or pointers. This constraint check is currently correct for objects
but not for procedures, and getting it right needs to avoid being
confused between pointers to procedures and pointers returned by
procedures.
Differential Revision: https://reviews.llvm.org/D155491
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
