[fparser2] Support statement functions

[rupertford]

No description provided.

[arporter]

This Issue came out of #171 which documents the problems with fparser2's existing support of Statement Functions. Basically, we cannot identify whether an array assignment immediately following the declaration section is in fact part of the declaration section and thus specifies a statement function. The only solution is to be able to check through all symbols currently in scope and see whether the variable on the LHS has already been declared as an array.

[rupertford]

Sorry for not describing the problem in this issue previously @mlange05, that is my bad. My only excuse is that most of the recent development has been done by us and we knew what the problem was. Here is some text from issue #171 which, as @arporter said, is where this issue came from.

This issue is indicative of a larger problem, which is that some Fortran parse rules can not be resolved in isolation and need symbol table information. The plan is to turn fparser2 into a 2-phase parser which gets symbols in phase 1 and uses those for context, where required, in phase2. The problem in this issue will be fixed by this change.

The statement function problem is that the rules for both an array access and a statement function match when the statement function is the last declaration or the array access is the first executable statement. These can only be distinguished by looking at symbol table information. As fparser2 just matches rules at the moment we could get incorrect code so I removed support, by commenting out the statement function matching rule. This can result in statement functions being wrongly matched as array accesses, but seeing as statement functions are less used than array accesses it was considered to be a lesser evil. In our offline discussion you rightly pointed out that I should have added associated failing tests (and explained what was going on in this issue!).

However, statement functions are not the only situation where there can be an ambiguity in Fortran. The other well known one is an array access or a function access e.g.

a = b(i)

Is b(i) an access to an array or a function passing i as an argument. In isolation there is no way to tell so we again need symbol table information to help decide.

Therefore, as stated in the quoted text, we need symbol table information. However I am not sure that we need to go for 2 phases, we could pick up symbols as we go along (I think). This issue should therefore be blocked on a separate issue which adds symbol table information. Issue #201 has been created for this.

[rupertford]

I have just had a look at the Fortran spec and the way to distinguish between the definition of a statement function and an access to an array seems to be to look at the declaration of the variable on the lhs and potentially its arguments. If this is (implicitly or explicitly) a scalar and we are in a declaration block then it is a statement function. If it is an array declaration and we are in an executable block then it is an array access. In addition, if it is a statement function then the lhs name can't be passed by argument. I don't think this helps clarify anything as, if the lhs is passed by argument a valid program would have to declare the argument as an array in any case.

The statement function, or array access, arguments should be declared (implicitly or explicitly) as scalars. If they are declared locally and the variable is not accessed before being used in the statement function then it is a statement function e.g.

subroutine what_am_I
real :: a
integer :: i
a(i) = 1.0

The problem occurs when the lhs has, or could have been, declared in another module and its type is unknown. For example, the following code snippet could be an array or a statement function depending on how 'a' is declared. If 'a' is declared as a scalar in the module then it is a statement function, if it is declared as an array in the module then it is an array and if it is not declared in the module then it is a statement function as the implicit typing rules declare 'a' to be a scalar

subroutine example
use my_mod
use my_mod2, only : i
a(i) = 1.0
end subroutine example

I suggest we look in the symbol table when it exists, see #201, and if the variable is not there then we raise an exception for the time being. In the future we could add an 'unknown' node and continue parsing.