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.

[LonelyCat124]

@hiker was this fixed by #1618 completion or is this still broken?

[arporter]

@stevemullerworth has just mentioned this bug so it is still a problem :-( As @sergisiso says above, I think we have to wait until we can get rid of the old fparser1-based path.

[arporter]

Example from Steve:

PSyclone - global optimisation working/skeleton/algorithm/test_alg_mod.x90
The same symbol 'field' is used for different datatypes, 'field_type, None' and 'r_tran_field_type, None'. This is not currently supported.


module test_alg_mod
  use constants_mod
  use field_mod, only : field_type
  use r_tran_field_mod, only : r_tran_field_type

  implicit none

contains

subroutine set_rdef(field)
  type(field_type),intent(inout) :: field

  call invoke(setval_c(field,0.0))
end subroutine set_rdef

subroutine set_rtran(field)
  type(r_tran_field_type),intent(inout) :: field

  call invoke(setval_c(field,0.0))
end subroutine set_rtran
end module test_alg_mod

[sergisiso]

PR #3402 may solve it. But we decided to wait until after the release to merge it since it is a big change to do that close to the release.