Use the upstream Fortran parser #3160
Conversation
See comment in the added code.
|
One more thing worth noting here is that previously there were 2 fortran parsers - F77 and FORTRAN. There's just a single after this PR which parses both dialects and TM_PARSER_F77 is set to some dummy value which can be replaced by some new parser (which could be for instance #3157). |
|
The I guess someone had added them to allow newer Fortrans to be parsed. They will need to re-add them upstream. [Edit: see here ] |
|
@elextr Thanks for digging this out - I was aware of the commit which however didn't explain exactly what was going on but the specification clarifies it. I'll prepare a patch for the upstream version and update this PR afterwards. |
|
Done, the change has been upstreamed so I updated the parser and the unit tests. |
|
@elextr Anything left here here to be fixed or does it look OK to you? |
|
LGB(quick)I, tests pass, some symbols show for random fortran from the interweb. |
Update qualified_types.f90 and members.f90 to remove the "kind" and "len" specifiers after integers. I haven't seen this usage documented anywhere and the syntax, when used should include braces such as integer(len=5). The previous Geany Fortran parser used to parse these but since I don't think it's a valid syntax, I didn't submit the corresponding patch upstream. The rest of the tests is mostly added function arguments and different names for anonymous tags.
To correctly rename anonymous tags the tag renaming function had to be updated for a special case in Fortran - see the commit for more details.
I also updated 2 unit tests which (I believe) contained invalid Fortran code the new parser didn't handle.