[all-commits] [llvm/llvm-project] 8b2904: [flang] Correct disambiguation of possible stateme...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8b2904826782b29187a757bfe2d1b97bbc4fabb8
      https://github.com/llvm/llvm-project/commit/8b2904826782b29187a757bfe2d1b97bbc4fabb8
  Author: Peter Klausler <pklausler at nvidia.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M flang/include/flang/Semantics/tools.h
    M flang/lib/Semantics/resolve-names.cpp
    M flang/lib/Semantics/tools.cpp
    M flang/test/Semantics/resolve08.f90
    A flang/test/Semantics/stmt-func02.f90

  Log Message:
  -----------
  [flang] Correct disambiguation of possible statement function definitions

The statement "A(J) = expr" could be an assignment to an element of an
array A, an assignment to the target of a pointer-valued function A, or
the definition of a new statement function in the local scope named A,
depending on whether it appears in (what might still be) the specification
part of a program or subprogram and what other declarations and definitions
for A might exist in the local scope or have been imported into it.

The standard requires that the name of a statement function appear in
an earlier type declaration statement if it is also the name of an
entity in the enclosing scope.  Some other Fortran compilers mistakenly
enforce that rule in the case of an assignment to the target of a
pointer-valued function in the containing scope, after misinterpreting
the assignment as a new local statement function definition.

This patch cleans up the handling of the various possibilities and
resolves what was a crash in the case of a statement function definition
whose name was the same as that of a procedure in the outer scope whose
result is *not* a pointer.

Differential Revision: https://reviews.llvm.org/D155493