[all-commits] [llvm/llvm-project] 010c55: [flang] Improve error recovery in tricky situation...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 010c55bf44144f6370a0c4995c30ec51b06e1efe
      https://github.com/llvm/llvm-project/commit/010c55bf44144f6370a0c4995c30ec51b06e1efe
  Author: Peter Klausler <35819229+klausler at users.noreply.github.com>
  Date:   2024-06-13 (Thu, 13 Jun 2024)

  Changed paths:
    M flang/lib/Parser/expr-parsers.cpp
    M flang/lib/Parser/program-parsers.cpp
    M flang/lib/Parser/token-parsers.h
    A flang/test/Parser/recovery01.f90
    A flang/test/Parser/recovery02.f90

  Log Message:
  -----------
  [flang] Improve error recovery in tricky situation (#95168)

When the very first statement of the executable part has syntax errors,
it's not at all obvious whether the error messages that are reported to
the user should be those from its failure to be the last statement of
the specification part or its failure to be the first executable
statement when both failures are at the same character in the cooked
character stream. Fortran makes this problem more exciting by allowing
statement function definitions look a lot like several executable
statements.

The current error recovery scheme for declaration constructs depends on
a look-ahead test to see whether the failed construct is actually the
first executable statement. This works fine when the first executable
statement is not in error, but should also allow for some error cases
that begin with the tokens of an executable statement.

This can obviously still go wrong for declaration constructs that are
unparseable and also have ambiguity in their leading tokens with
executable statements, but that seems to be a less likely case.

Also improves error recovery for parenthesized items.



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