search

stfc / fparser

This project maintains and develops a Fortran parser called fparser2 written purely in Python which supports Fortran 2003 and some Fortran 2008. A legacy parser fparser1 is also available but is not supported. The parsers were originally part of the f2py project by Pearu Peterson.
https://fparser.readthedocs.io
Other
64 stars 29 forks source link

Syntax error when parsing source which INCLUDEs an INTERFACE block. #412

Closed arporter closed 1 year ago

arporter commented 1 year ago

Parsing the following code:

      PROGRAM test_include
      INCLUDE 'mpif.h'
      WRITE(*,*) MPI_COMM_WORLD
      END

with the include path set to find the NVIDIA mpi header files gives:

File: 'fixed_form.f'
Syntax error: at line 2
>>>      INCLUDE 'mpif.h'

irrespective of whether the reader is set to free or fixed format.

arporter commented 1 year ago

This is with the OpenMPI header file.

arporter commented 1 year ago

All that the OpenMPI header file actually has in it is a bunch of INCLUDE statements. The one that causes problems is mpif-sizeof.h. If I manually inline it then it parses fine.

arporter commented 1 year ago

I can strip this file down until all that it contains is:

      INTERFACE MPI_Sizeof

      SUBROUTINE MPI_Sizeof_character_scalar(x, size, ierror)
      CHARACTER::x
        INTEGER, INTENT(OUT) :: size
        INTEGER, INTENT(OUT) :: ierror
      END SUBROUTINE MPI_Sizeof_character_scalar

      END INTERFACE MPI_Sizeof

and this still reproduces the error. If I replace the INTERFACE block with e.g. INTEGER mpi_comm_world then it parses fine. (The NVIDIA compiler is happy with the stripped down code containing the INTERFACE block.)

arporter commented 1 year ago

If I make both the top file and the include file free format (and tell the parser that it is free format) then the error still happens.

arporter commented 1 year ago

It turns out that when I last touched the 'include' functionality and 'tidied up' some of the code (https://github.com/stfc/fparser/pull/387/files#diff-45028ec9e913fdcc947a7dd36119c30a5c24c10922d285cae392f7acb6e1152f) I broke it. Now, the reader returns lines from the INCLUDE file in the opposite order! Presumably this is after a match has failed as we have test_readfortran.py::test_include2 which tests the reader only for pretty much the exact case we have here (mpif_sizeof.h). If I revert the code that handles reading from include files to the original form in the aforelinked diff then the parse is successful.

arporter commented 1 year ago

I've reverted to the old way of handling INCLUDE files and that fixes the current problem but also breaks the expected ordering of lines when an INCLUDE has an in-line comment. I'm wondering whether I can fix the put_item so that it always puts it in the FIFO of the 'innermost' reader object and then maybe I don't need to revert the other code?