[all-commits] [llvm/llvm-project] 50e1ad: [flang][Preprocessor] Constrain a bit more implici...

[Roger Ferrer Ibáñez via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 50e1ad6ed23682d3a992a2e8c8b7db64baaccb66
      https://github.com/llvm/llvm-project/commit/50e1ad6ed23682d3a992a2e8c8b7db64baaccb66
  Author: Roger Ferrer Ibanez <roger.ferrer at bsc.es>
  Date:   2023-08-23 (Wed, 23 Aug 2023)

  Changed paths:
    M flang/lib/Parser/preprocessor.cpp
    M flang/lib/Parser/preprocessor.h
    M flang/lib/Parser/prescan.cpp
    M flang/test/Preprocessing/implicit-contin1.F90
    A flang/test/Preprocessing/implicit-contin4.F90

  Log Message:
  -----------
  [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