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
61 stars 29 forks source link

fparser2: generate correct OPEN call when unit number argument is not named #36

Closed arporter closed 6 years ago

arporter commented 7 years ago

When parsing the following OPEN call:

OPEN( idrst, FILE = TRIM(cdname), FORM = 'unformatted', ACCESS = 'direct'   &
        &       , RECL = 8, STATUS = 'old', ACTION = 'read', IOSTAT = ios, ERR = 987 )

fparser2 generates:

OPEN(UNIT = <class 'fparser.Fortran2003.File_Unit_Number'>, FILE = TRIM(cdname), FORM = 'unformatted', ACCESS = 'direct', RECL = 8, STATUS = 'old', ACTION = 'read', IOSTAT = ios, ERR = 987)

i.e. the fact that the unit number argument isn't named in the original call appears to cause problems.

arporter commented 6 years ago

I've fixed this on branch open_wo_named_unit. The match method was returning File_Unit_Number instead of File_Unit_Number(string). I've added tests for both OPEN and the associated Connection_Spec.

In doing this I've discovered that classes such as blah_List (e.g. Connection_Spec_List) or Scalar_blah are generated at runtime (at the end of the Fortran2003.py module). This is why we get so many pylint errors about undefined variables.

arporter commented 6 years ago

I've also realised that, because of the auto-generation of some classes, the match method does need to catch NoMatchError. I've therefore put this back in the match method of the Inquire_Spec class (I removed it in #35 because I thought it was unnecessary).