#469 Removed the creation of parsable_x90 files. Fixes #458.

[hiker]

This only addresses the removal of the parsable_x90 files (and therefore fixes #458, and part of #469).

The removal itself was quick, but it caused a bug in the filenames used for the .an files.

Originally, the PSyclone step would create a .an file based on the parsed parsable_x90 file, e.g. sci_null_preconditioner_alg_mod.2456263381.an, storing AnalysedX90 data.
After processing with PSyclone, a new analyse step will analyse the algorithm layer file and create a new .an file. In the example above, it created sci_null_preconditioner_alg_mod.3489817750.an

The hash value used is based on the .x90 file, and the difference is caused by the changes caused by removing the comments and invoke names while making the files parsable (so I would actually suspect if we had a x90 files without invoke names and without comments, we would hit the same bug).

When the step to make the files parsable was skipped, the hash code used for the two .an files was the same (i.e. the X90 analyse file of the x90 file, and the psy-layer file using the x90 has was identical), so the x90 .an file was considered to be a prebuild, and Fab tried to load this 'prebuild as AnalysedFortran (which then of course failed).

In order to avoid this, I have changed the way the file name for the .an files are created: I leave the suffix (.f90 or .x90) attached to the names, so we now get two files :

sci_null_preconditioner_alg_mod.f90.3489817750.an
sci_null_preconditioner_alg_mod.x90.3489817750.an

This makes is a lot easier to see where the files came from (in the original scheme there was only a difference in the hash, and you could not easily 'see' which one was which).

As a result, I had to modify some additional tests to accommodate this change in file names.

[hiker]

Note that I have compiled several LFRic applications without any changes required. The only effect for an existing build would be that the prebuilds are not found the first time.

[hiker]

@yaswant , @MatthewHambley , @Pierre-siddall , @t00sa - ready for review.

[MatthewHambley]

A question.

[MatthewHambley]

The code removed by this change handles the fact that keyword arguments may not appear before positional arguments in Fortran. Presumably this doesn't trip up fParser like it was feared it might, which is why it can be removed. However, it doesn't change the fact that it is syntactically invalid. Are there any safeguards in place to deal with fParser suddenly deciding to care about this? Are we relying on the fact that it will throw a syntax error and we will fix it then?

[hiker]

I've provided details in #458 (comment):
The name= at the beginning is valid according to the Fortran grammar (as in the EBNF rules), it's only a constrain rule that does not allow this. Besides, PSyclone relies on this behaviour, and this step was only done for PSyclone anyway. If a future Fortran standard should change the grammar, then when fparser adopts it, there must be a way for PSyclone to continue to work (can't say how ;) ), and Fab will be able to utilise the same solution.

Edit: But yes, we would rely that if fparser doesn't accept it, it would raise an error (with or without this step), and for the same reasons PSyclone would stop to work.

TBH, no idea why the Fortran standard was written this way, would have been quite easy to specify this as a proper rule instead of as a constrained. Then again, for LFRic, having the name AFTER the code would not be ideal ;)

[hiker]

FWIW:

R401 xyz-list            is xyz [ , xyz ] ...
R1520 function-reference is procedure-designator ( [ actual-arg-spec-list ] )
R1521 call-stmt          is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ]
R1523 actual-arg-spec    is [ keyword = ] actual-arg