Error when parsing FUNCTIONS declared both with a return type and a RESULT clause

[remi-kazeroni]

What happened?

When parsing and regenerating a FUNCTION that is declared with a return type, the return type keyword is removed from the prefix specifications and replaced by a declaration of the function's result. The syntax is different but the behavior of the function has not changed.

For example, parsing and regenerating this function:

REAL FUNCTION square(a)
    IMPLICIT NONE
    REAL, INTENT(IN) :: a
    square = a * a
END FUNCTION square

leads to:

FUNCTION square(a)
    IMPLICIT NONE
    REAL :: square
    REAL, INTENT(IN) :: a
    square = a * a
END FUNCTION square

Howerer, if a RESULT clause is added to the function declaration, this leads to an incorrect inference of the result and thus to a error when compiling the regenerated code. For example, parsing and regenerating this function:

REAL FUNCTION square(a) result(b)
    IMPLICIT NONE
    REAL, INTENT(IN) :: a
    b = a * a
END FUNCTION square

leads to:

FUNCTION square (a) RESULT(b)
      IMPLICIT NONE
      REAL :: square ! this should be REAL :: b
      REAL, INTENT(IN) :: a
      b = a*a
    END FUNCTION square

where the declared result should b instead of square.

We are not sure how the wrong result inference should be addressed. Keeping the result type in the declaration (as in other programing languages) would be nice but not necessary.

What are the steps to reproduce the bug?

fcode = """
REAL FUNCTION square(a) result(b)
  IMPLICIT NONE
  REAL, INTENT(IN) :: a
  b = a * a
END FUNCTION square
""".strip()
square = Subroutine.from_source(fcode)
print(square.result_name)   # b
print(square.return_type)    # None
print(square.to_fortran())

The output is:

    b
    None
    FUNCTION square (a) RESULT(b)
      IMPLICIT NONE
      REAL :: square
      REAL, INTENT(IN) :: a
      
      b = a*a
    END FUNCTION square

Version

0.3.1

Platform (OS and architecture)

Red Hat Enterprise Linux 9.2 - Python 3.12.7

Relevant log output

Accompanying data

No response

Organisation

IPSL