Incorrect parsing of an assignment into a Stmt_Function

[sergisiso]

When parsing this function from nemolite2d:

   subroutine field_copy_code(ji, jj, output, input)
     implicit none
     integer,                  intent(in)  :: ji, jj
     real(wp), dimension(:,:), intent(in)  :: input
     real(wp), dimension(:,:), intent(out) :: output

     output(ji,jj) = input(ji,jj)
   end subroutine field_copy_code

The output(ji,jj) = input(ji,jj) is parsed as a Stmt_Function_Stmt inside the SpecificationPart, and I believe it should be an assignment on the ExecutionPart.

The relevant Fortran rules are:
R1237 stmt-function-stmt is function-name ( [ dummy-arg-name-list ] ) = scalar-expr

C1264 (R1237) The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar.

And in this case function-name is specified to be an array.

[rupertford]

I've verified this problem. The following cut down version also returns the assignment as a statement function

   subroutine field_copy_code()
     output(ji,jj) = input(ji,jj)
   end subroutine field_copy_code

Program(Subroutine_Subprogram(Subroutine_Stmt(None, Name('field_copy_code'), None, None), Specification_Part(Stmt_Function_Stmt(Name('output'), Dummy_Arg_Name_List(',', (Name('ji'), Name('jj'))), Part_Ref(Name('input'), Section_Subscript_List(',', (Name('ji'), Name('jj')))))), End_Subroutine_Stmt('SUBROUTINE', Name('field_copy_code'))))

Notice, the Stmt_Function_Stmt inside the Specification_Part.

[rupertford]

Created branch assign_not_statementfunction

[rupertford]

To start off with I've added repr as an option to the fparser2.py script so that I can more easily see the types of objects generated by fparser2. I still need to update the documentation to reflect this addition.

[rupertford]

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.

However, this does not help @sergisiso who is waiting on this fix. What I will do is create a temporary hack branch which removes the statement function match which will hopefully allow @sergisiso to make progress.

[rupertford]

Created branch sergi_sf_hack

[rupertford]

This branch removes the statement function match, adds a minimal example and updates the fparser2 script to output 'repr' for testing.

To test ...

> cd fparser/src/fparser
> scripts/fparser2.py sergi_example.f90 
SUBROUTINE field_copy_code
  output(ji, jj) = input(ji, jj)
END SUBROUTINE field_copy_code

Program(Subroutine_Subprogram(Subroutine_Stmt(None, Name('field_copy_code'), None, None), Execution_Part(Assignment_Stmt(Part_Ref(Name('output'), Section_Subscript_List(',', (Name('ji'), Name('jj')))), '=', Part_Ref(Name('input'), Section_Subscript_List(',', (Name('ji'), Name('jj')))))), End_Subroutine_Stmt('SUBROUTINE', Name('field_copy_code'))), Comment(''))

You can see that we now have an assignment statement in the execution part.

[rupertford]

For the time being I think it makes sense to move the "hack" onto master. The reason for this is that statement functions are not often used so support for them is unlikely to be missed.

[rupertford]

pr #200 is on master. Closing this issue.