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.
A procedure designator cannot be coindexed, except for cases in which the coindexing doesn't matter (i.e. a binding that can't be overridden).
A coarray must not have a zero extent on a codimension; that would yield an empty coarray. When cobounds are constants, verify them.
Refine handling of NULL(...) in semantics to properly distinguish NULL(), NULL(objectPointer), NULL(procPointer), and NULL(allocatable) from each other in relevant contexts. Add IsNullAllocatable() and IsNullPointerOrAllocatable() utility functions. IsNullAllocatable() is true only for NULL(allocatable); it is false for a bare NULL(), which can be detected independently with IsBareNullPointer(). IsNullPointer() now returns false for NULL(allocatable). ALLOCATED(NULL(allocatable)) now works, and folds to .FALSE. These utilities were modified to accept const pointer arguments rather than const references; I usually prefer this style when the result should clearly be false for a null argument (in the C sense), and it helped me find all of their use sites in the code.
The definition of an array constructor doesn't preclude the use of [character(:)::] or [character(*)::] directly, but there is language elsewhere in the standard that restricts their use to specific contexts, neither of which include explicitly typed array constructors. Fixes https://github.com/llvm/llvm-project/issues/128755.
A few bits of semantic checking need a variant of the ResolveAssociations utility function that stops when hitting a construct entity for a type or class guard. This is necessary for cases like the bug below where the analysis is concerned with the type of the name in context, rather than its shape or storage or whatever. So add a flag to ResolveAssociations and GetAssociationRoot to make this happen, and use it at the appropriate call sites. Fixes https://github.com/llvm/llvm-project/issues/128608.
Move non-common files from FortranCommon to FortranSupport (analogous to
LLVMSupport) such that
* declarations and definitions that are only used by the Flang compiler,
but not by the runtime, are moved to FortranSupport
* declarations and definitions that are used by both ("common"), the
compiler and the runtime, remain in FortranCommon
* generic STL-like/ADT/utility classes and algorithms remain in
FortranCommon
This allows a for cleaner separation between compiler and runtime
components, which are compiled differently. For instance, runtime
sources must not use STL's `<optional>` which causes problems with CUDA
support. Instead, the surrogate header `flang/Common/optional.h` must be
used. This PR fixes this for `fast-int-sel.h`.
Declarations in include/Runtime are also used by both, but are
header-only. `ISO_Fortran_binding_wrapper.h`, a header used by compiler
and runtime, is also moved into FortranCommon.
Currently the use of REAL/COMPLEX(KIND=10) as a type or literal constant suffix elicits an optional warning message only. This leads to compiler internal errors during lowering when these types appear in code being compiled to non-x86_64 targets. For better error messaging, make the use of these types a hard error in semantics instead when they are not supported by the target architecture.
A non-elemental specific procedure must take precedence over an elemental specific procedure in defined operator generic resolution. Fixes https://github.com/llvm/llvm-project/issues/124777.