Same symbol used for different datatypes.

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 :(

@rupertford

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.

@hiker

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.

Yes, I am happy to wait.

@hiker

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

@stevemullerworth

@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.

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

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.

Navigation Menu

Repository navigation

Same symbol used for different datatypes. #2113

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Same symbol used for different datatypes. #2113

Description

Activity

sergisiso commented on Apr 19, 2023

rupertford commented on Apr 19, 2023

hiker commented on Apr 19, 2023

LonelyCat124 commented on Jun 11, 2025

arporter commented on Jun 12, 2026

arporter commented on Jun 12, 2026

sergisiso commented on Jun 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions