Fix issue flang-compiler/f18#574.
Array references can be mistaken for function references during
parsing. This is handled and fixed by semantics. however, if the
symbol in the misparsed array reference was construct associated,
then semantics was not handling the case correctly because
semantics was only expecting `ObjectEntityDetails`.
It was not possible to change the related `GetUltimate` into
`GetAssociationRoot` because associated symbols are not always
associated to another symbol (variable) but may be assoicated to
an expression. Hence, this change allow `AssocEntityDetails` to
be also accepted when dealing with array references misparsed as
function references.
Original-commit: flang-compiler/f18@
b6a8b5f42bdb40d65f4c242a3673bc436a2d0601
Reviewed-on: https://github.com/flang-compiler/f18/pull/672
Tree-same-pre-rewrite: false
},
proc.u)}) {
Symbol &symbol{origSymbol->GetUltimate()};
- if (symbol.has<semantics::ObjectEntityDetails>()) {
+ if (symbol.has<semantics::ObjectEntityDetails>() ||
+ symbol.has<semantics::AssocEntityDetails>()) {
if constexpr (common::HasMember<common::Indirection<parser::Designator>,
uType>) {
CheckFuncRefToArrayElementRefHasSubscripts(context, funcRef);
return; // reported error
}
if (IsProcedure(*symbol) || symbol->has<DerivedTypeDetails>() ||
- symbol->has<ObjectEntityDetails>()) {
+ symbol->has<ObjectEntityDetails>() ||
+ symbol->has<AssocEntityDetails>()) {
// these are all valid as procedure-designators
} else if (symbol->test(Symbol::Flag::Implicit)) {
Say(name,