INTENT, VALUE, and OPTIONAL attributes apply only to dummy arguments. A
couple older compilers accept them, usually with a warning, if they are
applied to names that are not dummy arguments, and they show up in some
older non-portable source code. Change these cases into stern warnings
by default.
A procedure pointer is allowed to be initialized with the subprogram in
which it is local, assuming that other requirements are satisfied.
Add a good test for local procedure pointer initialization, as no test
existed for the error message in question.
Fixes https://github.com/llvm/llvm-project/issues/116566.
The standard doesn't require that an interoperable procedure's dummy
arguments have interoperable derived types in some cases. Although
nearly all extant Fortran compilers emit errors, some don't, and things
should work; so reduce the current fatal error message to an optional
portability warning.
Fixes https://github.com/llvm/llvm-project/issues/115010.
When a separate module procedure has a dummy procedure argument that is
simply declared EXTERNAL in its interface but is actually called as a
subroutine or function in its definition, the compiler is emitting an
error message. This is too strong; an error is appropriate only when the
dummy procedure in the definition has an interface that is incompatible
with the one in the interface definition.
However, this is not a safe coding practice, and can lead to trouble
during execution if a function is passed as an actual argument but
called as a subroutine in the procedure (or the other way around), so
add a warning message as well for this case (off by default).
Fixes https://github.com/llvm/llvm-project/issues/110797.
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
It is a non-mandatory error to reference an external procedure via an
implicit interface declaration (EXTERNAL or PROCEDURE()) when the
external procedure has an interface that requires the presence of an
explicit interface to be called.
Until now, the compiler has issued a fatal error message from semantics
for this situation. But (1) there are situations, such as passing such
an EXTERNAL as an actual argument, or as the target of a procedure
pointer assignment, where little or no harm is done, (2) other compilers
don't/can't detect this error, even when the procedure's definition is
in the same source file, and (3) it shows up in some real applications.
So downgrade this error to a stern warning. Perhaps in the future the
compiler could resume emission of a hard error in the cases where the
EXTERNAL procedure is actually known to be called via its implicit
interface.
When a module file has been compiled with CUDA enabled, don't emit
spurious errors about non-interoperable types when that module is read
by a USE statement in a later non-CUDA compilation.
When USE association encounters a conflict that can't be resolved, it
produces a "UseError" symbol that will trigger an error message if that
symbol is ever actually used. UseError symbols that aren't used are
benign.
Ensure that UseError symbols don't run the gamut of declaration
checking. They were getting through, and could lead to spurious error
messages.
Fixes https://github.com/llvm/llvm-project/issues/106020.
FindPolymorphicAllocatableUltimateComponent needs to be
FindPolymorphicAllocatablePotentialComponent. The current search is
missing cases where a derived type has an allocatable component whose
type has a polymorphic allocatable component.
…DATA
We allow automatic data objects in the specification part of the main
program; add an optional portability warning and documentation. Don't
allow them in BLOCK DATA. They're already disallowed as module
variables.
Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such references would
resolve to symbols in the enclosing scope.)
This change causes the symbols for the type parameters to be created
when the TYPE statement is processed in name resolution. They are
TypeParamDetails symbols with no KIND/LEN attribute set, and they shadow
any symbols of the same name in the enclosing scope.
When the type parameter declarations are processed, the KIND/LEN
attributes are set. Any earlier reference to a type parameter with no
KIND/LEN attribute elicits an error.
Some members of TypeParamDetails have been retyped &/or renamed.
f18 current emits an error when an assignment is made to an array
section with a vector subscript, and the array is finalized with a
non-elemental final subroutine. Some other compilers emit this error
because (I think) they want variables to only be finalized in place, not
by a subroutine call involving copy-in & copy-out of the finalized
elements.
Since many other Fortran compilers can handle this case, and there's
nothing in the standards to preclude it, let's downgrade this error
message to a portability warning.
This patch got complicated because the API for the WhyNotDefinable()
utility routine was such that it would return a message only in error
cases, and there was no provision for returning non-fatal messages. It
now returns either nothing, a fatal message, or a non-fatal warning
message, and all of its call sites have been modified to cope.
Make the results of the two IsInteroperableIntrinsicType() utility
routines a tri-state std::optional<bool> so that cases where the
character length is simply unknown can be distinguished from those cases
where the length is known and not acceptable. Use this distinction to
not emit a confusing warning about interoperability with C_LOC()
arguments when the length is unknown and might well be acceptable during
execution.
Transformational functions from the intrinsic module ISO_C_BINDING are
allowed in specification expressions, so tweak some general checks that
would otherwise trigger error messages about inadmissible targets, dummy
procedures in specification expressions, and pure procedures with impure
dummy procedures.
SIZEOF and C_SIZEOF were broken for assumed-ranks because
`TypeAndShape::MeasureSizeInBytes` behaved as a scalar because the
`TypeAndShape::shape_` member was the same for scalar and assumed-ranks.
The easy fix would have been to add special handling in
`MeasureSizeInBytes` for assumed-ranks using the TypeAndShape
attributes, but I think this solution would leave `TypeAndShape::shape_`
manipulation fragile to future developers. Hence, I went for the
solution that turn shape_ into a `std::optional<Shape>`.
… that's not BIND(C)
An interoperable BIND(C) object with a derived type should have a
BIND(C) derived type, but will now work with a derived type that
satisfies all of the requirements of a BIND(C) derived type.
Prevent messages from module files, respect the language feature flags
when enabling the relaxed PURE dummy argument checking, and check that
the new warnings are enabled.
No specification expression in the declaration of the result variable of
an elemental function may depend on the value of a dummy argument. This
ensures that all of the results have the same type when the elemental
function is applied to the elements of an array.
Allow an explicit BIND(C) derived type to have a non-BIND(C) component
so long as the component's type is interoperable and it satisfies all
other constraints.
…ned operators
The checks for conflicts between defined operators/assignments and the
intrinsic operators/assignment need to take CUDA procedure and data
attributes into account to avoid false positive error messages.
The standard requires that dummy arguments to PURE functions be
INTENT(IN) or VALUE, but PURE subroutines are allowed to have modifiable
dummy arguments. This makes it impossible to declare atomic operations
as PURE functions, which consequently makes such atomic operations
ineligible for use in parallel constructs and DO CONCURRENT.
This patch downgrades this error to a warning by default, which can be
seen with -pedantic & al. and remain an error with -Werror.
Two checks related to BIND(C) vs non-BIND(C) entry points with the same
dummy argument added by https://github.com/llvm/llvm-project/pull/92474
have turned out to be unnecessary. Revert them and adjust the tests.
I modified declaration checking for interoperable objects to buffer its
generated messages as I had previously done for derived types and
procedure interfaces, but failed to modify all of the message creation
statements to use the new buffer, so some are now escaping when a module
file is being compiled. Fix to ensure that the new buffer is always
used.
A type-bound procedure that's bound to a name that isn't a procedure is
caught as an error, but can also lead to a crash in compatibility
checking later. Make that code more robust to failure.
Fixes https://github.com/llvm/llvm-project/issues/92678.
As was done recently to allow derived types that are not explicitly
BIND(C), but meet the requirements of BIND(C), to be acceptable for use
in contexts nominally requiring BIND(C), this patch allows procedures
that are not explicitly BIND(C) to be used in contexts that nominally
require BIND(C) so long as (1) they meet the requirements of BIND(C),
and (2) don't use dummy arguments whose implementations may vary under
BIND(C), such as VALUE.
When a BIND(C) interface or subprogram has a dummy argument whose
derived type is not BIND(C) but meets the constraints and requirements
of a BIND(C) type, accept it with a warning.
When a procedure is defined with a subprogram but never referenced in a
compilation unit, it may not be characterized until lowering, and any
errors in characterization then may crash the compiler. So always ensure
that procedure definitions are characterizable in declaration checking.
Fixes https://github.com/llvm/llvm-project/issues/91845.
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.
