The restriction was completely removed in #89677. This was a bit too
much. Reapply the restriction on elemental, pure and recursive but only
for kernel subprogram (`grid_global` and `global` attributes).
There are two constraints in the language that prohibit the use of an
ENTRY name being used as the RESULT() variable of the function or
another ENTRY name in the same function's scope; neither can the name of
the function be used as the RESULT() of an ENTRY.
Move most of the existing partial enforcement of these constraints from
name resolution into declaration checking, complete it, and add more
cases to the tests.
A derived type that meets (most of) the requirements of an interoperable
type but doesn't actually have the BIND(C) attribute can be accepted as
an interoperable type, with optional warnings.
Move EQUIVALENCE object checking from resolve-names-utils.cpp to
check-declarations.cpp, where it can work on fully resolved symbols and
reduce clutter in name resolution. Add a check for EQUIVALENCE objects
that are not ObjectEntityDetails symbols so that attempts to equivalence
a procedure are caught.
…Warn()
Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.
Declaration checking is looking for inappropriate usage of the INTENT,
VALUE, & OPTIONAL attributes in multiple places, and some oddball cases
like ENTRY points are not checked. Centralize the check for attributes
that apply only to dummy arguments into one spot.
An apparent attempt to override a type-bound procedure is not allowed to
be interpreted as on override when the procedure is PRIVATE and the
override attempt appears in another module. However, if the TBP that
would have been overridden is a DEFERRED procedure in an abstract base
type, the override must take place. PRIVATE DEFERRED procedures must
therefore have all of their overrides appear in the same module as the
abstract base type.
Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in symbol table
entries with ProcEntityDetails. The raw symbol of the interface needs to
be the one used for emitting procedure symbols to module files.
Fixes https://github.com/llvm/llvm-project/issues/83836.
The check for declarations of polymorphic entities was emitting a bogus
error for one (or more) layers of pointers to procedures returning
pointers to polymorphic types.
Fixes https://github.com/llvm/llvm-project/issues/83292.
…istinguishing characteristic
We note whether a procedure's interface is explicit or implicit as an
attribute of its characteristics, so that other semantics can be checked
appropriately, but this internal attribute should not be used as a
distinguishing characteristic in itself.
Fixes https://github.com/llvm/llvm-project/issues/81876.
Object with the CONSTANT attribute cannot be declared in the host
subprogram.
It can be declared in a module or a device subprogram.
Adapt the semantic check to trigger the error in host subprogram.
Ensure that the compiler emits a hard error for a generic interface with
ambiguous specific procedures when it is declared as such, and the
ambiguity doesn't involve optional or unlimited polymorphic dummy data
arguments. But: emit an optional portability warning when the ambiguity
in the generic interface is due to USE association's merging of multiple
generics, as USE association may involve modules not under control of
the programmer; we'll emit a hard error message if any the actual
arguments in a particular reference to the generic procedure doesn't
resolve to exactly one specific procedure. And don't emit warnings when
potential ambiguity due to USE association is taking place in a module
file; the warnings, if any, will have been produced when the module file
was compiled.
When a compilation unit has an interface to an external subroutine or
function, and there is a global object (like a module) with the same
name, we're emitting an error. This is too strong, the program will
still build. This comes up in real applications, too. Downgrade the
error to a warning.
A recent patch to allow pFUnit to compile softened the diagnostic about
indistinguishable specific procedures to a portability warning. It turns
out that this was overkill -- for specific procedures containing no
optional or unlimited polymorphic dummy data arguments, a diagnosis of
"indistinguishable" can still be a hard error.
So adjust the analysis to be tri-state: two procedures are either
definitely distinguishable, definitely indistinguishable without
optionals or unlimited polymorphics, or indeterminate. Emit errors as
before for the definitely indistinguishable cases; continue to emit
portability warnings for the indeterminate cases.
When this patch is merged, all but one of the dozen or so tests that I
disabled in llvm-test-suite can be re-enabled.
When a generic procedure interface, either declared or the result of
merging two use-associated generics, has two specific procedures
that are not distinguishable according to the rules in F'2023
subclause 15.4.3.4.5, emit a portability warning rather than a
hard error message. The rules in that subclause are not adequate
to detect pairs of specific procedures that admit an ambiguous
reference, as demonstrated by a case that arose in pFUnit. Further,
these distinguishability checks, even if sufficient to the task
of detecting pairs of specifics capable of ambiguous references,
should only apply to pairs where *every* reference would have to
be ambiguous -- and this can and is validated at every reference
anyway. Last, only XLF enforces these incomplete and needless
distinguishability rules -- every other compiler seems to just
check that each procedure reference resolves to exactly one
specific procedure.
If the standard were to complete lose subclause 15.4.3.4.5 and
its related note (C.11.6) -- which admits that the rules are
incomplete! -- and simply require that each generic procedure
reference resolve unambiguously to exactly one specific, nobody
would miss them. This patch changes this compiler to give them
lip service when requested, but they are now otherwise ignored.
Using the VALUE attribute for assumed-length CHARACTER dummy arguments
became standard in F'2008 but still lacks widespread implementation;
emit a portability warning when they are enabled.
Resolves llvm-test-suite/Fortran/gfortran/regression/value_5.f90.
Recognize Cray pointees as such when they are declared as assumed size
arrays, and don't emit a bogus error message about implied shape arrays.
Fixes https://github.com/llvm/llvm-project/issues/77330.
Although COMMON variables implicitly have the SAVE attribute, and
variables with the SAVE attribute are generally disallowed in PURE
subprograms, we must allow the use of COMMON in PURE as an exception.
F'2023 constraint C1598 applies only to local variables.
…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
