[flang][Preprocessor] Constrain a bit more implicit continuations

D155499 fixed an issue with implicit continuations. The fixes included a
nested parenthesis check during definition of a macro which

[flang][Preprocessor] Constrain a bit more implicit continuations

D155499 fixed an issue with implicit continuations. The fixes included a
nested parenthesis check during definition of a macro which is then
carried over in the scanner state.

This leads to the following corner case to fail:

subroutine foo(a, d)
implicit none
integer :: a
integer :: d

! An implicit continuation won't be considered unless
! the definition of "bar" above is removed/commented
call sub(1,
2)
end subroutine foo

The definition of bar is indeed unbalanced but it is not even used in
the code, so it should not impact whether we apply implicit continuation
in the expansion of sub.

This change aims at addressing this issue by removing the balance check
and constraining a bit more when we consider implicit continuations:
only when we see a left parenthesis after a function-like macro, not a
object-like macro. In this case I think it is OK to (unconditionally)
implicitly continue to the next line in search of the corresponding
right parenthesis. This is, to my understanding, similar to what the C
preprocessor would do according to the description in [1].

[1] https://www.spinellis.gr/blog/20060626/

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

show more ...

[flang] Stricter "implicit continuation" in preprocessing

The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may spa

[flang] Stricter "implicit continuation" in preprocessing

The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may span multiple lines. In an attempt to work more like a
Fortran-oblivious C preprocessor, the prescanner will act as if
the following lines had been continuations so that the function-like
macro could be invoked.

This still seems like a good idea, but a recent bug report on
LLVM's GitHub issue tracker shows one way in which it could trigger
inadvertently and mess up a program. So this patch makes the
conditions for implicit line continuation much more strict.

First, the leading parenthesis has to have been preceded by an
identifier that's known to be a macro name. (It doesn't have to
be a function-like macro, since it's possible for a keyword-like
macro to expand to the name of a function-like macro.) Second,
no macro definition can ever have had unbalanced parentheses in
its replacement text.

Also cleans up some parenthesis recognition code to fix some
issues found in testing, so that a token with leading or trailing
spaces can still be recognized as a parenthesis or comma.

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

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

show more ...