Standards Conformance

This document discusses the language that FLPR recognizes, and where there are deficiencies.

Standards Basis

This implementation is based on the 28-DEC-2017 Draft N2146 of the ISO/IEC JTC1/SC22/WG5 Fortran Language Standard, available from the Fortran Working Group. As such, it targets the language of the Fortran 2018 standard.

Explicit Deviations

There are several situations where we have elected not to conform with the Fortran specification:

  1. The FLPR parser is sensitive to whitespace in the input text in both free and fixed source form. This is a deviation from Section 6.3.3.1.2. If you have very traditional fixed form source code which does not use spaces to delimit names and keywords, you will need to preprocess that source code with another tool before processing it with FLPR.
  2. The FLPR parser does not recognize any nondefault character set.
  3. FLPR does not enforce the constraints of the standard, and thus, is not a standard-conforming processor. See the Potential “gotchas” section for an example.

Retro-Extensions

Some features that have been deleted or made obsolescent in the current standard have been implemented to assist modernization efforts:

  • FORTRAN 77 kind-selector (e.g. real*8)
  • computed-goto-stmt
  • arithmetic-if-stmt
  • forall-stmt
  • label-do-stmt
  • nonblock-do-construct: FLPR introduces a non-standard executable-construct, called nonblock-do-construct, to handle parsing of F2008 action-term-do-construct and outer-shared-do-construct.
  • The concurrent-locality rule for the CONCURRENT clause of loop-control has been made optional to allow loop-control to match F2008 forall-header CONCURRENT clauses.

Note that Hollerith constants are not implemented.

Incomplete Sub-statement Parsing

There are situations where FLPR does not build a completely elaborated concrete syntax tree for a statement. For example, the syntax rules:

  • expr
  • io-control-spec-list
  • position-spec-list

are examples of incomplete parsers in FLPR (there are many). The expected behavior is that FLPR will indicate a range of tokens that would be matched by these rules, but present them as a simple sequence rather than as a tree.

FLPR is implemented in a top-down fashion, so the user should expect that FLPR can parse the general structure of a program, but the details of an individual statement may not be fully elaborated.

Known Deficiencies

There are some parsers that simply have not been implemented yet. The current list includes:

  • block-data
  • change-team-construct
  • critical-construct
  • submodule

These will be implemented soon, but if one in particular is holding you up, please file an issue on GitHub. Contributions are always welcome!

Potential “gotchas”

  • FLPR ignores Fortran include directives and all preprocessor symbols, so it may get confused if you depend on macro expansion or file inclusion to produce valid Fortran. Note that there is an internal FLPR preprocessor, but it only works when directed to.
  • FLPR parsers produce concrete syntax trees, which include all of the punctuation and layout information. These are challenging to extract information from. See the function has_call_named() in apps/module.cc for an example of how to traverse the concrete syntax tree. Going forward, more abstract representations will be introduced.
  • Note that FLPR enforces the rules of the standard, but not the constraints. This will allow FLPR to accept input that will be rejected by a conforming compiler. For example, rule R1164 defines sync-all-stmt as “SYNC ALL [([ sync-stat-list ])]”, and constraint C1171 specifies that a specifier may not appear in the sync-stat-list more than once. FLPR does not enforce that constraint.
  • When looking for an action-stmt in the input to transform, remember to look “inside” if-stmt, which contain an action-stmt!