lanl / flpr Goto Github PK

The grammar for type-declaration-stmt is (R801):

declaration-type-spec [ [ , attr-spec] ... :: ] entity-decl-list

which is fine, except that that is no easy way to identify the token range that one would use to make a new variable of this type. I'm going to introduce a new non-terminal:

type-decl-attr-seq is declaration-type-spec [ [ , attr-spec ] ... :: ]

to allow an easier time picking apart the statement. This will cause a change from R801:

type-declaration-stmt is type-decl-attr-seq entity-decl-list

Add a new application that prints the Stmt_Tree for one statement obtained on stdin. This helps analyze Stmt_Tree structure.

The Stmt_Tree for CALL foo(a) is coming out as:

call-stmt <CALL procedure-designator <data-ref <part-ref <name ( section-subscript-list <section-subscript <int-expr <expr > > > ) > > > >

which is incorrectly marking the substring (a) as a data-ref rather than an actual-arg-spec-list.

Under flpr-format -fi, include lines are not being reindented.

As an example of FLPR functionality, create an application that generates a module containing interface declarations for top-level procedures in a list of input files.

• Implement bind-stmt parser
• Add test cases
• Update documentation

The ability to reindent a file is currently held in apps/flpr_format_base.cc, but it is generally useful capability to repair generated files. Move this capability to flpr/Parsed_File.hh, because that holds all the information required to do reindentation.

• add codimension-stmt parser
• add test cases
• update documentation

• add value-stmt parser
• add test cases
• update documentation

flpr-format has a stub implementation for a feature to elaborate external subprogram end statements into its full form (e.g. END FUNCTION function-name). This needs to be fleshed out.

1. move to module_base structure, similar to flpr_format_base.
2. integrate local changes to make the demo a bit more useable.

Although the standard specifies that the character "!" initiates a comment in fixed source form, old compilers simply ignored any text past the last column (normally column 72), effectively making them comments regardless of their contents.

I'm building a standalone application that depends on FLPR and I am using CMake for my build system. Recent-ish versions of CMake allow for downloading and building remote dependencies with the ExternalProject and FetchContent facilities. FetchContent is especially nice for including dependencies that also use CMake. So, for example, my application's CMakeFiles.txt contains:

include(FetchContent)
set(FLPR_SOURCE_DIR "${CMAKE_CURRENT_BINARY_DIR}/FLPR-source")
FetchContent_Declare(FLPR
  GIT_REPOSITORY https://github.com/lanl/FLPR.git
  GIT_TAG        HEAD
  SOURCE_DIR     "${FLPR_SOURCE_DIR}"
)
FetchContent_MakeAvailable(FLPR)

which will retrieve the FLPR source from GitHub and place it in build/FLPR-source, then perform some CMake magic to build it. So far, so good: you should see this pull and attempt to build FLPR with CMake.

The issue seems to be one of CMake module detection and pathing; the build fails with:

CMake Error at build/FLPR-source/CMakeLists.txt:18 (include):
  include could not find load file:

    BuildType


CMake Error at build/FLPR-source/CMakeLists.txt:19 (include):
  include could not find load file:

    CompilerFlags

Both BuildType.cmake and CompilerFlags.cmake exist under build/FLPR-source/cmake with appropriate permissions (as expected) but it seems like CMake is searching for them under <my project root>/cmake instead (where it should look for these files when it's normally built as a standalone project). That is, the errors disappear if I copy BuildType.cmake and CompilerFlags.cmake to <my project root>/cmake.

I believe the critical lines of FLPR's CMakeLists.txt are

# Allow CMake to find some project include files
list (INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake")

but I don't have a good idea of how to appropriately set CMAKE_MODULE_PATH in a submodule; what's needed is the child's version of "${CMAKE_SOURCE_DIR}/cmake", not the parent's.

I'm not sure if this configuration mismatch is on my side or not; I'm still digging into it.

1. add missing parser for asynchronous-stmt
2. update Sphinx documentation

Should be able to register descriptive strings and types for client Syntax_Tag extensions.

1. Add missing generic-stmt parser
2. Update Sphinx documentation

It would be nice to have an option to remove an unlabelled return statement immediately preceding a procedure END statement.

I was torture-testing parse_files on some old EISPACK code and I ran across an idiom that causes indigestion:

       do 100 i = mp1, igh
100    z(i,mp) = a(i,mp-1)

It appears that having the do-terminating line label assigned to something other than continue causes an unrecognized statement error. Moving 100 to a continue statement solves this problem. I also tested adding more lines between do and the terminating 100 but that had no effect.

This is bad style in modern code but it's unfortunately common in legacy code; not surprising that it tripped up the parser (hence the torture testing...)

• add protected-stmt parser
• add unit tests
• fix sphinx documentation

Under flpr-format -fi, labels are not being formatted the same as in emacs: they should be left-justified

The parser for the team-variable parameter to form-team-stmt is consuming a trailing form-team-spec-list.

• Add missing pointer-stmt parser
• Update Sphinx documentation

• add new keywords to flex scanner
• implement parser
• add tests
• update documentation

Currently, DOUBLE PRECISION is recognized by FLPR::Stmt::intrinsic_type_spec() as two keywords. This makes it difficult for users to identify the meaning of this sequence. Suggest adding a "smashed" keyword for all non-END* entries in Smash_Hash.gperf.