Use associated procedure pointers were eliciting bogus errors from
semantics if their modules also contained generic procedure interfaces
of the same name. (The compiler handles this case correctly when the
specific procedure of the same name is not a pointer.)
With this fix, the test case in
https://github.com/llvm/llvm-project/issues/107784
no longer experiences semantic errors; however, it now crashes
unexpectedly in lowering.
A defined assignment generic interface for a given LHS/RHS type & rank
combination may have a specific procedure with LHS dummy argument that
is neither allocatable nor pointer, or specific procedure(s) whose LHS
dummy arguments are allocatable or pointer. It is possible to have two
specific procedures if one's LHS dummy argument is allocatable and the
other's is pointer.
However, the runtime doesn't work with LHS dummy arguments that are
allocatable, and will crash with a mysterious "invalid descriptor" error
message.
Extend the list of special bindings to include
ScalarAllocatableAssignment and ScalarPointerAssignment, use them when
appropriate in the runtime type information tables, and handle them in
Assign() in the runtime support library.
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.
Most warnings should be silenced when processing the content of a module
file, since the warning should have also appeared when the module file
was generated. The case of an intrinsic type kind not being supported
for a target wasn't being suppressed; fix.
Fixes https://github.com/llvm/llvm-project/issues/107337.
When the implementation of one SMP apparently references another in what
might be a specification expression, semantics may need to resolve it as
a forward reference, and to allow for the replacement of a
SubprogramNameDetails place-holding symbol with the final
SubprogramDetails symbol. Otherwise, as in the bug report below,
confusing error messages may result.
(The reference in question isn't really in the specification part of a
subprogram, but due to the syntactic ambiguity between the array element
assignment statement and a statement function definition, it appears to
be so at the time that the reference is processed.)
I needed to make DumpSymbols() available via SemanticsContext to analyze
this bug, and left that new API in place to make things easier next
time.
Fixes https://github.com/llvm/llvm-project/issues/106705.
…uctors
A non-conforming extension to Fortran present in a couple other
compilers is allowing a anonymous component in a structure constructor
to initialize a parent (or greater ancestor) component. This was working
in this compiler only for direct parents, and only when the type was not
use-associated.
Fixes https://github.com/llvm/llvm-project/issues/102557.
The check for a structure constructor to a forward-referenced derived
type wasn't tripping for constructors in the type definition itself. Set
the forward reference flag unconditionally at the beginning of name
resolution for the type definition.
Derived type assignment checking needs to account for the possibility of
derived assignment. The implementation was checking compile-time
conformance errors only on the path for assignments of intrinsic types.
Add a static array conformance check in the derived type flow once it
has been established that no defined assignment exists.
Fixes https://github.com/llvm/llvm-project/issues/98981.
Pull request https://github.com/llvm/llvm-project/pull/97337 was
reverted by https://github.com/llvm/llvm-project/pull/98612 due
to two failing tests in llvm-test-suite -- which I ran, as always,
but must have bungled or misinterpreted (mea culpa).
The failing tests were llvm-test-suite/Fortran/gfortran/regression/
char_length_{20,21}.f90. They have array constructors with
explicit character types whose dynamic length values are negative
at runtime, which must be interpreted as zero.
This patch extends the original to cover those cases.
Reverts llvm/llvm-project#97337
This has caused llvm test suite failures on our bots, for example:
https://lab.llvm.org/buildbot/#/builders/17/builds/709
```
FAIL: test-suite::gfortran-regression-execute-regression__char_length_21_f90.test
FAIL: test-suite::gfortran-regression-execute-regression__char_length_20_f90.test
```
Data designators like "a(j:k)" are parsed into array section references,
but once rank and type information is in hand, some of them turn out to
actually be substring references. The code that recognizes these cases
was suffering from a "false positive" in the case of a construct entity
in a SELECT RANK construct due to the use of a predicate member function
(Symbol::IsObjectArray) that only works on ObjectEntityDetails symbols.
Fix the test to use the more general Symbol::Rank() member function.
An implied DO loop with no trips in an array constructor does not have a
well-defined character length unless its data items have a length that
is constant expression. That works, but the implementation is too
broadly applied. An array constructor with an explicit type-spec always
has a well-defined length.
F'2023 allows BOZ to appear in more contexts, including the common
extension of the right-hand side of an assignment to an INTEGER or REAL
variable. Implement that one case now.
In accordance with other compilers, don't require that a %REF() actual
argument be a modifiable variable. And move the %REF/%VAL semantic
checks to Semantics/check-call.cpp, where one would expect to find them.
Fixes https://github.com/llvm/llvm-project/issues/93489.
We currently complain that the argument may not be a procedure, which is
confusing. Distinguish the NULL() case from other error cases (which are
indeed procedures). And clean up the utility predicates used for these
tests -- the current IsProcedure() is really just a test for a procedure
designator.
The type of "[lo:hi:str]" is being forced to INTEGER(8), ignoring the
types of the operands to the triplet. The type of a triplet should be
whatever the type of "lo+hi+str" would be.
(Array constructor triplets are a syntactic sugar extension for an
implied DO loop.)
Fortran has an ambiguously defined rule about the typing of index
variables of implied DO loops in DATA statements and array constructors
that omit an explicit type specification. Such indices have the type
that they would have "if they were variables" in the innermost enclosing
scope. Although this could, and perhaps should, be read to mean that
implicit typing rules active in that innermost enclosing scope should be
applied, every other Fortran compiler interprets that language to mean
that if there is a type declaration for that name that is visible from
the enclosing scope, it is applied, and it is an error if that type is
not integer.
Fixes https://github.com/llvm/llvm-project/issues/91053.
…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.
When the interface of a procedure is implicit at the point of call,
don't perform actual argument type conversion to the types of the dummy
arguments. This was inadvertently taking place in a case where the
procedure has an implicit interface but was also defined in the same
source file, so that its characteristics were known.
When the characteristics of a procedure depend on a procedure that
hasn't yet been defined, the compiler currently emits an unconditional
error message. This includes the case of a procedure whose
characteristics depend, perhaps indirectly, on itself. However, in the
case where the characteristics of a procedure are needed to resolve a
generic, we should not emit an error for a hitherto undefined procedure
-- either the call will resolve to another specific procedure, in which
case the error is spurious, or it won't, and then an error will issue
anyway.
Fixes https://github.com/llvm/llvm-project/issues/88677.
https://github.com/llvm/llvm-project/pull/78593 changed expression
semantics to always include the names of parent components that were
necessary to access an inherited component. This turns out to have
broken calls to inherited NOPASS procedure bindings. Update the patch to
omit explicit parent components when accessing bindings, while retaining
them for component accesses (including procedure components).
When a Hollerith actual argument is associated with an unlimited
polymorphic dummy argument, it's treated as if it were CHARACTER. Some
other compilers treat it as if it had been BOZ, so emit a portability
warning.
Resolves https://github.com/llvm/llvm-project/issues/83548.
…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.
When statement function expressions are analyzed, ensure that the
semantics context has a valid location set, otherwise a type spec (like
"integer::") can lead to a crash.
Fixes https://github.com/llvm/llvm-project/issues/80532.
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.
…edures
Fortran allows a generic interface to have the same name as a derived
type in the same scope. It also allows a generic interface to have the
same name as one of its specific procedures.
When two modules define the same name, possibly more than once each,
things get exciting. The standard is not clear, and other compilers do
variously different things. We are currently emitting some errors
prematurely for some usage in pfUnit due to how it combines two versions
of a package together via USE association.
This patch handles combinations of derived types and generic interfaces
and their specific procedures in a more principled way. Errors due to
ambiguity are deferred to actual usage of derived types and specific
procedures -- and when they're not used, the program is unambiguous and
no error issues.
For simplicity, lowering relies on semantics expansion of parent
components in designators.
This was not done in `call x%p()` where `p` is a procedure component
pointer of a parent component of `x`.
Do it and turn lowering TODO into a new lowering TODO for `call bar(x%type_bound_procedure)` (passing a tybe bound procedure is allowed as an extension, but lowering does not handle this extension yet. This is a lowering issue, will do in different patch).
In
CALL FOO
PRINT *, ABS(FOO)
we currently resolve the first FOO to a global external subprogram, but
then the second FOO is treated as an implicitly typed local variable.
This happens because the name FOO is not present in the local scope.
Fix by adding FOO to the local scope using a place-holding
HostAssocDetails symbol whose existence prevents the creation of another
FOO in the local scope. The symbol stored in the parser::Name parse tree
nodes or used in typed expressions will all continue to point to the
global external subprogram.
Resolves llvm-test-suite/Fortran/gfortran/regression/pr71859.f90.
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.
Compilation-time subscript value range checking should emit a warning,
not an error, when the indexed array is a dummy argument; there's
old-school codes out there that should have used assumed-size dummy
arguments but didn't.
When the bounds of a substring reference are known during compilation,
and are outside the valid range for the character base object, issue an
error message.
Update evaluate::ActualArgument to propagate the %VAL and %REF markers
until lowering.
Semantic checks are added to %VAL to ensure the argument is a numerical
or logical scalar.
I did not push these markers into the characteristics because other
compilers do not complain about inconsistent usages (e.g. using %VAL in
a call on a procedure with an interface without VALUE dummies is not
flagged by any compilers I tested, and it is not an issue for lowering,
so I decided to stay simple here and minimize the footprint of these
legacy features).
Lowering retrieves these markers and does the right thing: pass %VAL in
registers and pass %REF by address without adding any extra arguments
for characters.
The front-end is making implicit conversions explicit in assignment and
structure constructors.
While this generally helps and is needed by semantics to fold structure
constructors correctly, this is incorrect when the LHS or component is
an allocatable. The RHS may have non default lower bounds that should be
propagated to the LHS, and making the conversion explicit changes the
semantics. In the structure constructor, the situation is even worse
since Fortran 2018 7.5.10 point 7 allows the value to be a reference to
an unallocated allocatable, and adding an explicit conversion in
semantics will cause a segfault.
This patch removes the explicit convert in semantics when the
LHS/component is a whole allocatable, and update lowering to deal with
the conversion insertion, dealing with preserving the lower bounds and
the tricky structure constructor case.
A RANK(*) case in a SELECT RANK construct selects the case of an
assumed-rank dummy argument whose effective actual argument is an
assumed-size array. In this case, the attributes of the selector are
those of a rank-1 assumed-size array, and the selector cannot be
allocatable or a pointer.
Ensure that the representation of a SELECT RANK construct's per-case
AssocEntityDetails can distinguish RANK(n), RANK(*), and RANK DEFAULT,
and clean up various code sites and tests where the distinctions matter.
Fortran allows an earlier-declared KIND type parameter of a parameterized
derived type to be used in the constant expression defining the integer
kind of a later type parameter.
TYPE :: T(K,L)
INTEGER, KIND :: K
INTEGER(K), LEN :: L
...
END TYPE
Differential Revision: https://reviews.llvm.org/D159044https://reviews.llvm.org/D159044
The flag "anyIntrinsicDefinedOps" is always set nowadays, as there are intrinsic
modules that define operator(==) and (!=). This disables the iterative
expression analysis mechanism, also unnecessarily, and it is possible to
overflow the stack when analyzing very deep expression trees like the ones
that show up in artificial stress tests. Remove the flag.
Differential Revision: https://reviews.llvm.org/D159022
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
Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associated with named constants or
subobjects of named constants that are sporting non-default lower bounds.
Sometimes the non-default lower bounds matter, sometimes they don't.
Add a fairly exhaustive test to work through the possibilities.
Differential Revision: https://reviews.llvm.org/D156756
An implied DO loop in an array constructor may not have a type (explicit
or otherwise) with a character length that depends on a value of an
implied DO index or a non-constant expression if the implied DO loop
executes no iterations. When the iteration count can be known to be
zero at compilation time, catch the case of a non-constant length
expression correctly.
Differential Revision: https://reviews.llvm.org/D156753
When a generic interface X has a specific procedure Y that is also a specific
procedure of another generic with the same name (Y), ensure that
generic resolution of a call to X that resolves to Y points to the
symbol of the specific procedure Y, not the generic.
Differential Revision: https://reviews.llvm.org/D156341
