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 #define sub(x, y) foo2(x, y) #define bar ) ! 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].