Future strategy regarding frontends

[reuterbal]

What maintenance does this project need?

We need to have a discussion on the future of Loki frontends.

Fparser is being actively worked on, is the most complete and our standard frontend.

Our use of OMNI compiler depends on the specific OMNI version packaged in the CLAW repository. That version is a few years old and doesn't build with newer compiler versions, e.g., GNU10+, anymore. But even the latest updates on the upstream OMNI compiler repository have been more than 2 years ago: https://github.com/omni-compiler/omni-compiler
Our Github CI currently runs with the ubuntu 20.04 runners, which will likely be EOL some time next year, when that Ubuntu version goes out of maintenance. Hence, we have a call to make regarding the future of OMNI in Loki.

The Open Fortran Parser relies on an outdated Python package that wraps an old ROSE compiler frontend version. We have already earmarked this for removal (#209).

The question is whether

• we would be comfortable relying on a single frontend, or
• if we should expend effort to either update one of the others to a more recent version
• explore other frontend options in lieu

Various options exist for the last:

• Use an up-to-date ROSE compiler version, which may provide other Python binding options
• Explore Fxtran as a frontend
• Explore Lfortran as a frontend
• ...?

Organisation

No response

[reuterbal]

As explained in #408, removing CLAW allows to upgrade OMNI to the most recent release which currently remains compatible with the latest compiler versions and CI runners. If anything, this buys us a little time...

[reuterbal]

PR #411 implements the deprecation of OFP for the next Loki release (v0.2.8?). The intention is to remove the frontend entirely in the release following after that (could justify a version increase as v0.3.0?).

As expected, this reduces the test coverage because the translation from the OFP parse tree to the Loki IR is no longer covered in the tests, and alongside the relevant constructors for Sourcefile, Subroutine, Module, etc. However, it incurred also a number of indirect coverage regressions due to code paths that only exist for OFP. These would have to be removed together with the frontend, or need to receive dedicated tests.

The following indirect coverage regressions are capture by codecov:

• loki/frontend/source.py: extract_source and extract_source_from_range
  https://github.com/ecmwf-ifs/loki/blob/main/loki/frontend/source.py#L371-L438
• loki/tools/files.py: The decorator @disk_cached is only used for OFP
  https://github.com/ecmwf-ifs/loki/blob/main/loki/tools/files.py#L186-L227
• loki/expression/tests/test_expression.py: test_data_declaration is xfailing for both OMNI and FP
  https://github.com/ecmwf-ifs/loki/blob/main/loki/expression/tests/test_expression.py#L844-L878
• loki/frontend/preprocessing.py: reinsert_contiguous was only required for OFP
  https://github.com/ecmwf-ifs/loki/blob/main/loki/frontend/preprocessing.py#L129-L138
• loki/ir/nodes.py: Import.__repr__ is somehow no longer covered by tests?
  https://github.com/ecmwf-ifs/loki/blob/main/loki/ir/nodes.py#L1423-L1427
• loki/scope.py: SymbolTable.__repr__ is somehow no longer covered by tests?
  

  loki/loki/scope.py

  Lines 181 to 182 in 56ab8d7

  	def __repr__(self):
  	return f'<loki.types.SymbolTable object at {hex(id(self))}>'

I suspect the last two may be false negatives, but the others appear to be genuine.