When descriptor dummy args have ignore_tkr(c), we want to use the
descriptor unchanged. As such, disable various semantic error checks
that are normally performed on descriptor based dummy args without
ignore_tkr(c)
PROCEDURE(CLASS(...)) specifies a procedure with an implicit interface
whose result is polymorphic. That turns out to never be a valid
declaration, since a CLASS(...) function result is required to also be
POINTER or ALLOCATABLE, both of which require the presence of an
explicit interface. We caught this error already, but the message should
be improved for procedures.
Fixes https://github.com/llvm/llvm-project/issues/176861.
ISO Fortran now accepts a non-pointer actual argument to associate with
a dummy argument with the POINTER attribute if it is also INTENT(IN), so
long as the actual argument is a valid target for the pointer. But
passed-object dummy arguments still have a blanket prohibition against
being pointers in the ISO standard. Relax that constraint in the case of
INTENT(IN) so that passed objects can also benefit from the feature.
Fixes https://github.com/llvm/llvm-project/issues/172157.
Implemented IGNORE_TKR(P), which allows ignoring pointer and allocatable
matching (can pass an allocatable array to routine with pointer array
argument and vice versa). Updated documentation.
When an external procedure has an explicit interface in one scope, and
an implicit interface in another, and there's at least one call to it
from which dummy argument information can be inferred, don't emit a
warning about potential incompatibility if the only difference in their
characteristics is that one of their interfaces was implicit.
Audit the use of std::optional<bool> as a tri-state logical value in
flang, correct a couple cases that need ".value_or()", add some explicit
".has_value()" calls, and document the possible pitfalls.
When the same generic interface is processed via USE association from
its original module file and from a copy in a hermetic module file, we
need to do a better job at detecting and omitting duplicate specific
procedures. They won't have the same symbol addresses, but they will
have the same name, module name, and characteristics. This will avoid a
bogus error about multiple specific procedures matching the actual
arguments later when the merged generic interface is referenced.
COMMON block checks are split between name resolution and declaration
checking. We generally want declaration checks to take place after name
resolution, and the COMMON block checks that are currently in name
resolution have some derived type analyses that are redundant with the
derived type component iteration framework used elsewhere in semantics.
So move as much as possible into declaration checking, use the component
iteration framework, and cope with the missing COMMON block name case
that arises with blank COMMON when placing the error messages.
Added IsAlternateEntry() and modified IsExternalProcedureDefinition() to
also check for alternate entries.
(IsExternalProcedureDefinition() is called from
CheckHelper::CheckGlobalName(), which checks for duplicate global
symbols.)
Fixes#62778
This change modifies the messages API to make it impossible to forget to
call ShouldWarn by moving the call inside of the API. The low level API
should be avoided and developers should call Warn on a SemanticContext
or FoldingContext.
New implementation of `MayNeedCopy()` is used to consolidate
copy-in/copy-out checks.
`IsAssumedShape()` and `IsAssumedRank()` were simplified and are both
now in `Fortran::semantics` workspace.
`preparePresentUserCallActualArgument()` in lowering was modified to use
`MayNeedCopyInOut()`
Fixes https://github.com/llvm/llvm-project/issues/138471
Fortran's intrinsic numeric and relational operators can be overridden
with explicit interfaces so long as one or more of the dummy arguments
have the DEVICE attribute. Semantics already allows this without
complaint, but fails to replace the operations with the defined specific
procedure calls when analyzing expressions.
The global name semantic check was firing in a bogus way when BIND(C)
variables are in hermetic module.
Do not raise the error if one of the symbol with the conflicting global
name is an "hermetic variant" of the other.
Inaccessible procedure bindings can't be overridden, but DEFERRED
bindings must be in a non-abstract extension. We presently emit an error
for an attempt to override an inaccessible binding in this case. But
some compilers accept this usage, and since it seems safe enough, I'll
allow it with an optional warning. Codes can avoid this warning and
conform to the standard by changing the deferred bindings to be public.
An assignment to a whole polymorphic object in a PURE subprogram that is
implemented by means of a defined assignment procedure shouldn't be
subjected to the same definability checks as it would be for an
intrinsic assignment (which would also require it to be allocatable).
Fixes https://github.com/llvm/llvm-project/issues/139129.
This PR:
- makes Cray pointer declarations shadow previous bindings instead of
modifying them,
- errors when the pointee of a cray pointee has the SAVE attribute, and
- adds a missing newline after dumping the list of cray pointers in a
scope.
Closes#135579
A PURE subprogram can't have a local variable with the SAVE attribute.
An ASSOCIATE or SELECT TYPE construct entity whose selector is a
variable will return true from IsSave(); exclude them from the local
variable check.
Fixes https://github.com/llvm/llvm-project/issues/131356.
Two messages that complain about local variables mention that they don't
have the SAVE attribute; in both cases, it would be okay if they were
ALLOCATABLE instead. Clarify the messages.
I merged a patch yesterday
(https://github.com/llvm/llvm-project/pull/128980) that strengthened
error detection of indistinguishable specific procedures in a type-bound
generic procedure, and broke a couple of tests. Refine the check so that
it doesn't flag valid cases of overridden bindings, and add a thorough
test with all of the boundary cases that I can think of.
The code that checks for conflicts between type-bound defined I/O
generic procedures and non-type-bound defined I/O interfaces only works
when then procedures are defined in the same module as subroutines. It
doesn't catch conflicts when either are external procedures, procedure
pointers, dummy procedures, &c. Extend the checking to cover those cases
as well.
Fixes https://github.com/llvm/llvm-project/issues/128752.
…cific
When checking generic procedures for indistinguishable specific
procedures, don't neglect to include specific procedures from any
accessible instance of the generic procedure inherited from its parent
type..
Fixes https://github.com/llvm/llvm-project/issues/128760.
Enforce an obscure constraint from the standard: an abstract interface
is not allowed to have the same name as an intrinsic type keyword. I
suspect this is meant to prevent a declaration like "PROCEDURE(REAL),
POINTER :: P" from being ambiguous.
Fixes https://github.com/llvm/llvm-project/issues/128744.
When checking for conflicts between type-bound generic defined I/O
procedures and non-type-bound defined I/O generic interfaces, don't
worry about conflicts where the type-bound generic interface is
inaccessible in the scope around the non-type-bound interface.
Fixes https://github.com/llvm/llvm-project/issues/126797.
The check that "v_list" be deferred shape is just wrong; there are no
deferred shape non-pointer non-allocatable dummy arguments in Fortran.
Correct to check for an assumed shape dummy argument. And de-split the
error messages that were split across multiple source lines, making them
much harder to find with grep.
Fixes https://github.com/llvm/llvm-project/issues/125878.
The event variable in an EVENT POST/WAIT statement can be a coarray
reference, and need not be an entire coarray.
Variables and potential subobject components with EVENT_TYPE/LOCK_TYPE
must be coarrays, unless they are potential subobjects nested within
coarrays or pointers.
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.
