Same symbol used for different datatypes.

[hiker]

PSyclone cannot parse LFRic's mesh/reference_element_mod.F90 (which was triggered by my dependency analysis for the LFRic driver creation, typically this file is not touched by PSyclone):

The same symbol 'edges' is used for different datatypes, 'real, r_def' and 'integer, i_def'. This is not currently supported.

This is apparently caused by several subroutine/functions using the argument same name for different types - besides edges the name this is a major issue - reference_element_mod.F90 has three different this :(

In order to parse this file, I had to rename many, many variables to avoid these 'name clashes' in parameter names. E.g.:

<     subroutine face_on_edge_iface( this_ret, edges_idef )
---
>     subroutine face_on_edge_iface( this, edges )
218,219c218,219
<       class(reference_element_type), intent(in) :: this_ret
<       integer(i_def), intent(out) :: edges_idef(:,:)
---
>       class(reference_element_type), intent(in) :: this
>       integer(i_def), intent(out) :: edges(:,:)

...

1596c1596
<   subroutine reference_prism_destructor( this_rpt )
---
>   subroutine reference_prism_destructor( this )
1600c1600
<     type(reference_prism_type), intent(inout) :: this_rpt
---
>     type(reference_prism_type), intent(inout) :: this

Once I've renamed these arguments, it parsed fine :( That's a really annoying bug :(

[sergisiso]

Note that this is not a problem in the PSyIR Fortran reader. This error is raised in parse/algorithm.py that directly reads the fparser tree to create the algorithms layer. @rupertford has been redesigning this bit to create the algorithms layer by raising the representation from the PSyIR. Hopefully this issue goes away with the new codepath.

[rupertford]

Are you OK to wait for the new implementation @hiker assuming it fixes the problem? I'm hoping it should on master in around a month, but that relies on no significant issues when trying on all LFRic algorithm files. The issue is #1618.

[hiker]

Yes, I am happy to wait.