When a pointer component has no default initialization in the derived
type definition and does not appear explicitly as a component in a
structure constructor, we assume that it is meant to be NULL() as an
extension. But there's no warning or documentation for this extension;
add them.
Fixes https://github.com/llvm/llvm-project/issues/179580.
I'm emitting a false warning "used without definition" warning for
variable cited in an inquiry intrinsic (e.g. LBOUND), and failing to
emit an "unused local" warning for allocatables that only appear in
ALLOCATE statements.
This patch makes the analysis more context-aware by rewriting it in
terms of typed expression traversal, and moves the analysis part into
Evaluate/check-expression.cpp from Semantics/expression.cpp.
When scanning the specific procedures of a generic interface for a match
for a set of actual arguments, accept a constant actual argument as a
match for a dummy argument with the DEVICE attribute.
Tweak the implementations of IsConstantExpr, IsInitialDataTarget, and
related utilities so that "free" instances of array constructor implied
DO indices are not treated as constant expressions when the surrounding
context (if any) doesn't contain their bounds. This fixes a current bug
in which a "free" implied DO index in a structure constructor got
wrapped up an a Constant<SomeDerived>, which led to a crash in lowering.
Remove `AmbiguousStructureConstructor` warnings. This removes harmless
warnings about standards-conforming generic function references that
are never ambiguous with structure constructors.
Derived type procedure bindings aren't always subject to the checks of
the function-vs-subroutine classification flags on their symbol table
entries in name resolution, and we're missing some cases that aren't
caught later in expression semantics, which assumed that name resolution
would have already handled them. So check function-vs-subroutine errors
on bindings in expression semantics entirely.
Fixes https://github.com/llvm/llvm-project/issues/177601.
Follow-up to PR175211.
There are still a few AST nodes that don't have any of the standard
traits (Wrapper/Tuple/etc). Because of that they require special
handling in the parse tree visitor.
Convert a subset of these nodes to the typical format, and remove the
special cases from the parse tree visitor.
The members of these nodes were frequently used, so instead of
extracting them by hand each time use helper member functions to access
them.
Follow-up to PR175211.
There are still a few AST nodes that don't have any of the standard
traits (Wrapper/Tuple/etc). Because of that they require special
handling in the parse tree visitor.
Convert a subset of these nodes to the typical format, and remove the
special cases from the parse tree visitor.
Fortran allows a scalar actual argument of any type to correspond with a
TYPE(*) dummy argument that is an assumed-size array. This usage isn't
portable, and it didn't work with a generic procedure with this
compiler, only specific procedures. It affected at least one API in
OpenMPI.
Fix generic resolution to allow for this case, add a distinguishability
test to detect generic interfaces that have ambiguous specific
procedures due to it, and add an optional portability warning (off by
default).
There are quite a few AST nodes that don't have any of the standard
traits (Wrapper/Tuple/etc). Because of that they require special
handling in the parse tree visitor.
Convert a subset of these nodes to the typical format, and remove the
special cases from the parse tree visitor.
A substring reference where the lower bound is higher than the upper
bound is defined in 9.4.1 to be zero-length.
Thus, a reference to a substring of a CHARACTER*(0) string such as
string(foo():2)
cannot be a compile-time error since we do not know the return value of
foo().
We also should not error if the lbound > ubound at compile time.
Errors in array constructor values result in the array having
less elements than it should, which can cause other errors that
will confuse the user. Avoid this by not returning an expression
on errors.
Fixes#127425
When semantics is checking expressions in known dead branches of IF
constructs, errors should not be fatal; emit warnings instead, and allow
them to be disabled.
Fixes https://github.com/llvm/llvm-project/issues/171844.
Add a requested warning for completely unused local variables. The
implementation runs a scan over typed expressions during the existing
expression semantics pass to detect variable uses, and a routine at the
end of semantics to take a pass over the symbol tables to find unused
locals.
The new infrastructure needed to detect variable uses, and the existing
infrastructure that detects potential variable definitions, then makes
it easy to detect variables that are used without any possible
initialization or definition, so I did that too.
The warning for unused locals is off by default -- they might indicate a
misspelling (that IMPLICIT NONE would have caught), but seem otherwise
generally benign. The warning for uses of completely uninitialized and
undefined variables, however, is enabled by default, since that's likely
to indicate a program bug that should be investigated.
This patch touches a lot of files lightly. Many of these files are tests
that would have produced needless warning noise; one new test was added.
Fixes https://github.com/llvm/llvm-project/issues/173276.
When folding intrinsic function calls for types like REAL(2) that don't
have host math library support, we convert them to a type that has
greater range and precision, call a host math library routine that does
exist, and convert the result back to the original result type. The
folding of this second conversion can elicit floating-point warnings
(usually overflow) that are somewhat unclear to the user. Add support
for adding contextual information to these warnings.
When a generic procedure reference does not match any of its specific
procedures, run through them and emit the errors for each attempted
match, so that the user has more information to resolve the problem by
adjusting the actual arguments.
Fix a false positive "NULL can't be an operand here" error message
arising in a defined generic interface for an intrinsic operator (==)
with multiple spellings.
Fixes https://github.com/llvm/llvm-project/issues/163255.
Replace more parse tree references to "thing" and "value()" with usage
of the parser::Unwrap<> template function.
Add parser::UnwrapRef<> as an alias for DEREF(Unwrap<>()).
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.
As a common language extension, this compiler accepts a structure
constructor whose first value has no keyword and whose type matches an
ancestral type as if the constructor had had a keyword whose name was
the ancestral type. For example, given
TYPE PARENT; REAL X; END TYPE
TYPE, EXTENDS(PARENT) :: CHILD; END TYPE
we accept the nonconforming constructor "child(parent(1.))" as if it had
been the conforming "child(1.)" or "child(parent=parent(1.))".
The detection of this case needs to be constrained a bit to avoid a
false positive misinterpretation of conforming code in the case where
the actual first component of the derived type is a POINTER or
ALLOCATABLE whose type and rank would allow it to correspond with the
keywordless first value in the component value list.
Fixes https://github.com/llvm/llvm-project/issues/161887.
The compiler currently emit an error about the lack of an explicit
procedure interface when an external procedure that is called via an
implicit interface is known to have an dummy argument with a CUDA data
attribute, even when the corresponding actual argument does have a CUDA
data attribute. This behavior is inconsistent with what happens when
such a call is to an external in another source file and its definition
is not visible -- the compiler silently accepts an actual argument with
a CUDA data attribute across the implicit interface.
Harmonize this situation so that an actual argument with a CUDA data
attribute in a reference to a procedure with an implicit interface
elicits a usage warning encouraging the use of explicit interfaces. Only
when the procedure's definition is visible, and incompatible, will an
error message appear.
The code in expression semantics that catches a call to an impure
procedure in a PURE context misses calls to impure intrinsics, since
their designators have a SpecificIntrinsic rather than a Symbol. Replace
the current check with a new one that uses the characteristics of the
called procedure, which works for both intrinsic and non-intrinsic
cases.
Testing this change revealed that an explicit INTRINSIC statement wasn't
doing the right thing for extension "dual" intrinsics that can be called
as either a function or as a subroutine; the use of an INTRINSIC
statement would disallow its use as a subroutine. I've fixed that here
as well.
Fixes https://github.com/llvm/llvm-project/issues/157124.
In expression semantics, don't completely delete the unary plus
operator, but instead translate it into parentheses. The distinction
matters in contexts where the bounds of x are significant or when x must
not be misinterpreted as a variable.
Fixes https://github.com/llvm/llvm-project/issues/157379.
We emit an error on the component name in the structure constructor
"__builtin_c_ptr(__address=0)", which is the value of "c_ptr_null()",
because the component name "__address" is PRIVATE to an intrinsic
module. The error is specifically omitted, however, when the name
appears in a module file, since it's what we emit for "c_ptr_null()" in
initializers.
This patch carves out another exception -- downgrading the error to a
warning -- for the case of a PRIVATE component name in a structure
constructor from an intrinsic module when the structure constructor
appears in a module. This case arises when module files are being
reprocessed as Fortran source in order to convert them to hermetic
module files.
GNU Fortran added support for UNSIGNED ** UNSIGNED power operations; we
should do the same for portability. This actually simplifies semantics a
bit, since I had to go out of my way to exclude Power as a supported
operation for UNSIGNED.
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
When a REAL or COMPLEX literal appears without an explicit kind suffix
or a kind-determining exponent letter, and the conversion of that
literal from decimal to binary is inexact, emit a warning if that
constant is later implicitly widened to a more precise kind, since it
will have a different value than was probably intended.
Values that convert exactly from decimal to default real, e.g. 1.0 and
0.125, do not elicit this warning.
There are many contexts in which Fortran implicitly converts constants.
This patch covers name constant values, variable and component
initialization, constants in expressions, structure constructor
components, and array constructors.
For example, "real(8) :: tenth = 0.1" is a common Fortran bug that's
hard to find, and is one that often trips up even experienced Fortran
programmers. Unlike C and C++, the literal constant 0.1 is *not* double
precision by default, and it does not have the same value as 0.1d0 or
0.1_8 do when it is converted from decimal to real(4) and then to
real(8).
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.
When a type-bound generic ASSIGNMENT(=) procedure is ambiguous for a
particular reference, say so, rather than claiming that no specific
procedure matched the types and ranks of the LHS and RHS.
Fixes https://github.com/llvm/llvm-project/issues/148675.
When blank tokens arise from macro replacement in token sequences with
token pasting (##), the preprocessor is producing some bogus tokens
(e.g., "name(") that can lead to subtle bugs later when macro names are
not recognized as such.
The fix is to not paste tokens together when the result would not be a
valid Fortran or C token in the preprocessing context.
When a generic ASSIGNMENT(=) has elemental and non-elemental specific
procedures that match the actual arguments, the non-elemental procedure
must take precedence. We get this right for generics defined with
interface blocks, but the type-bound case fails if the non-elemental
specific takes a non-default PASS argument.
Fixes https://github.com/llvm/llvm-project/issues/141807.
When a TYPE(*) dummy argument is erroneously used as a component value
in a structure constructor, semantics crashes if the structure
constructor had been initially parsed as a potential function reference.
Clean out stale typed expressions when reanalyzing the reconstructed
parse subtree to ensure that errors are caught the next time around.
For more compatible legacy behavior on old tests, extend Hollerith
actual arguments on the right with trailing blanks out to a multiple of
8 bytes. Fixes Fujitsu test 0343_0069.
F'2023 allows the right-hand side of an assignment to an integer or real
scalar to be a BOZ literal constant; this has already been supported in
some compilers. The type of the left-hand side variable is used to
convert the value of the BOZ.
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.
Fortran 2023 constraint C7108 prohibits the use of a structure
constructor in a way that is ambiguous with a generic function reference
(intrinsic or user-defined). Sadly, no Fortran compiler implements this
constraint, and the common portable interpretation seems to be the
generic resolution, not the structure constructor.
Restructure the processing of structure constructors in expression
analysis so that it can be driven both from the parse tree as well as
from generic resolution, and then use it to detect ambigous structure
constructor / generic function cases, so that a portability warning can
be issued. And document this as a new intentional violation of the
standard in Extensions.md.
Fixes https://github.com/llvm/llvm-project/issues/138807.
Bring the typed expression representation of a coindexed reference up to
F'2023, which removed some restrictions that had allowed the current
representation to suffice for older revisions of the language. This new
representation is somewhat more simple -- it uses a DataRef as its base,
so any subscripts in a part-ref can be represented as an ArrayRef there.
Update the code that creates the CoarrayRef, and add more checking to
it, as well as actually capturing any STAT=, TEAM=, & TEAM_NUMBER=
specifiers that might appear. Enforce the constraint that the part-ref
must have subscripts if it is an array. (And update a pile of
copied-and-pasted test code that lacked such subscripts.)
Fortran::runtime::Descriptor::BytesFor() only works for Fortran
intrinsic types for which a C++ type counterpart exists, so it crashes
on some types that are legitimate Fortran types like REAL(2). Move some
logic from Evaluate into a new header in flang/Common, then use it to
avoid this needless dependence on C++.
Whole assumed-size arrays are generally not allowed outside specific
contexts, where expression analysis notes that they can appear. But
contexts can nest, and in the case of an actual argument that turns out
to be an array constructor, the permission to use a whole assumed-size
array must be rescinded.
Fixes https://github.com/llvm/llvm-project/issues/131909.
When reinterpreting an ambiguously parsed function reference as a
structure constructor, use the original symbol of the type in the
representation of the derived type spec of the structure constructor,
not its ultimate resolution. The distinction turns out to matter when
generating module files containing derived type constants as
initializers when the derived types' names have undergone USE
association renaming.
Fixes https://github.com/llvm/llvm-project/issues/131579.
These are constraints that preclude the need to obtain type information
from descriptors on other images, essentially. When designating a
polymorphic component, its base may not be coindexed; nor shall a
coindexed designator have a type with a polymorphic potential subobject
component.
F'2023 10.2.1.2 paragraph 2 imposes some requirements on the left-hand
sides of assignments when they have coindices, and one was not checked
while another was inaccurately checked. In short, intrinsic assignment
to a coindexed object can't change its type, and neither can it affect
allocatable components.
