| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
Variables that can't be BIND(C), like pointers, can't be in a BIND(C)
common block, either.
Fixes https://github.com/llvm/llvm-project/issues/148922.
|
|
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.
|
|
Catch assumed-rank arguments to defined I/O subroutines, and ensure that
v_list dummy arguments are vectors.
Fixes https://github.com/llvm/llvm-project/issues/138933.
|
|
Fixes https://github.com/llvm/llvm-project/issues/138915.
|
|
initialization (#136776)
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.
|
|
Only objects may have these types, or have potential subobject
components with these types.
|
|
Defined input/output subroutines must conform to documented interfaces
that do not allow for coarray dummy arguments.
|
|
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.
|
|
This patch fixes:
flang/lib/Semantics/check-declarations.cpp:2009:15: error: unused
variable 'kind' [-Werror,-Wunused-variable]
|
|
(#128980)
…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.
|
|
Detect and report a bunch of uncaught semantic errors with coarray
declarations. Add more tests, and clean up bad usage in existing tests.
|
|
|
|
An assumed-length character dummy argument is interoperable only if it
is neither a pointer nor allocatable.
|
|
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.
|
|
Generic operator/assignment checks for distinguishable specific
procedures must ignore inaccessible generic bindings.
Fixes https://github.com/llvm/llvm-project/issues/122764.
|
|
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.
|
|
(#115195)
SHARED attribute is explicitly meant to be used in device subprogram
(https://docs.nvidia.com/hpc-sdk/compilers/cuda-fortran-prog-guide/index.html#cfpg-var-qual-attr-shared).
Do not emit warning.
|
|
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.
|
|
(#102045)
…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.
|
|
We emit an incorrect error message when !DIR$ IGNORE_TKR appears in a
separate module procedure's interface declaration.
Fixes https://github.com/llvm/llvm-project/issues/98210.
|
|
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.
|
|
Catch some cases where assumed rank dummy arguments are not allowed.
|
|
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>`.
|
|
(#94768)
… 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.
|
|
(#94389)
…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.
|
