[all-commits] [llvm/llvm-project] fbbd8b: [flang] Fix rewriting of misparsed statement funct...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fbbd8b0741586794721639715d1d974db56f83ac
      https://github.com/llvm/llvm-project/commit/fbbd8b0741586794721639715d1d974db56f83ac
  Author: Peter Klausler <pklausler at nvidia.com>
  Date:   2024-11-05 (Tue, 05 Nov 2024)

  Changed paths:
    M flang/lib/Semantics/rewrite-parse-tree.cpp
    A flang/test/Semantics/rewrite03.f90

  Log Message:
  -----------
  [flang] Fix rewriting of misparsed statement functions (#112934)

Fortran's syntax is ambiguous for some assignment statements (to array
elements or to the targets of pointers returned by functions) that
appear as the first executable statements in a subprogram or BLOCK
construct. Is A(I)=X a statement function definition at the end of the
specification part, or ar array element assignment statement, or an
assignment to a pointer returned by a function named A?

Since f18 builds a parse tree for the entire source file before
beginning any semantic analysis, we can't tell which is which until
after name resolution, at which point the symbol table has been built.
So we have to walk the parse tree and rewrite some misparsed statement
function definitions that really were assignment statements.

There's a bug in that code, though, due to the fact that the
implementation used state in the parse tree walker to hold a list of
misparsed statement function definitions extracted from one
specification part to be reinserted at the beginning of the next
execution part that is visited; it didn't work for misparsed cases BLOCK
constructs. Their parse tree nodes encapsulate a parser::Block, not an
instance of the wrapper class parser::ExecutionPart. So misparsed
statement functions in BLOCK constructs were being rewritten into
assignment statement that were inserted at the beginning of the
executable part of the following subprogram, if and wherever one
happened to occur. This led to crashes in lowering and much
astonishment.

A simple fix would have been to adjust the rewriting code to always
insert the list at the next visited parser::Block, since
parser::ExecutionPart is just a wrapper around Block anyway; but this
patch goes further to do the "right thing", which is a restructuring of
the rewrite that avoids the use of state and any assumptions about parse
tree walking visitation order.

Fixes https://github.com/llvm/llvm-project/issues/112549.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications