search

camfort / fortran-src

Fortran parsing and static analysis infrastructure
https://hackage.haskell.org/package/fortran-src
Other
48 stars 20 forks source link

Add support for array specs in fortran 77 cray pointers #216

Open ProgramFan opened 2 years ago

ProgramFan commented 2 years ago

This PR adds a parsing rule to handle array specs in cray pointers in fixed-form fortran. The spec is from https://docs.oracle.com/cd/E19957-01/805-4941/z40000a54ba7/index.html. Basic tests with a simple fortran 77 source with -v f77l passed.

dorchard commented 2 years ago

Thanks for this! Would it be possible for you to put a comment in here to explain that this is for Cray pointers and also to add an example as a test in here: https://github.com/camfort/fortran-src/blob/master/test/Language/Fortran/Parser/Fixed/Fortran77/ParserSpec.hs?

ProgramFan commented 2 years ago

Thanks for the review. I am preparing it.

ProgramFan commented 2 years ago

I added two test cases for cray pointers in the aforementioned test suite, and also a comment line in Fortran77.y.

To be brief, this PR allows fortran-src to parse full cray pointers in fixed-form fortran 77 files. Cited from https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html:

Cray pointers are part of a non-standard extension that provides a C-like pointer in Fortran. This is accomplished through a pair of variables: an integer "pointer" that holds a memory address, and a "pointee" that is used to dereference the pointer.

Pointer/pointee pairs are declared in statements of the form:

pointer ( <pointer> , <pointee> )

or,

pointer ( <pointer1> , <pointee1> ), ( <pointer2> , <pointee2> ), ...

Current Fortran77.y does contain a rule POINTER_LIST to parse such pointers and an AST Node StPointer to store it in the parse tree. However, current grammar assumes pointee to be a scalar variable, while by definition it can be either a scalar or an array. This PR addresses this issue.

To allow for array pointees in cray pointers, this PR adds a matching rule in the POINTER matcher, which directly follows the grammar definition of an array pointee. However, since the AST chooses to store a single <pointer, pointee> pair as a declarator, we have to set the pointee as the declared variable and set the pointer as the initial value to make sense. So in addition to adding the new matching rule, I also swapped the pointer and pointee variable in the scalar pointee declarator definition.

I am open for any suggestions.

raehik commented 2 years ago

Thanks for this work.

I think we might want another Statement constructor for Cray pointers. StPointer is the standalone statement for the POINTER attribute. How about representing them as (Name, Expression) tuples? Expressions can be array accesses, so that's sorted. (I'm looking into this on my side.)

raehik commented 2 years ago

No, that's wrong, I see that pointees can be array declarators. I would still hazard making separate types/constructors for them rather than using Declarator etc., so we can get well-behaving instances (e.g. pretty printing).

ProgramFan commented 2 years ago

I agree with the idea of making separate constructors for cray pointers, since they can appear in both fixed and free form sources. It would also solve the awkward situation here that I need to workaround the limitation of Declarator. Unfortunately, I am still new to haskell, so I am afraid I am not capable of making such complex changes.