Select-Case conversion for Fortran

[pratikbhd]

This PR implements the following changes:

1. Implementation of Fortran select-cases in the Python IR and subsequent GrFN representation.
2. Added test cases to test for select-case conditions (python, GrFN, and lambda file comparison test)

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@9cba25e). Click here to learn what that means.
The diff coverage is 83.92%.

@@            Coverage Diff            @@
##             master     #422   +/-   ##
=========================================
  Coverage          ?   73.42%           
=========================================
  Files             ?       60           
  Lines             ?    13635           
  Branches          ?        0           
=========================================
  Hits              ?    10011           
  Misses            ?     3624           
  Partials          ?        0

Impacted Files	Coverage Δ
delphi/translators/for2py/preprocessor.py	76% <100%> (ø)
delphi/translators/for2py/f2grfn.py	65.65% <33.33%> (ø)
delphi/translators/for2py/genPGM.py	84.78% <75%> (ø)
delphi/translators/for2py/rectify.py	84.22% <80%> (ø)
delphi/translators/for2py/genCode.py	77.31% <85.71%> (ø)
delphi/translators/for2py/translate.py	87.28% <86.79%> (ø)
delphi/translators/for2py/pyTranslate.py	83.6% <91.95%> (ø)
delphi/translators/for2py/genModFileLog.py	59.59% <92.3%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9cba25e...f656dc0. Read the comment docs.

[skdebray]

@pratikbhd I was thinking about the "Inf" placeholder used to normalize CASE labels. Suppose the program has a variable named Inf, as shown in the program below. Would that cause a name conflict in the translation?

      program f
      implicit none
      integer i
      integer, parameter :: Inf = 5
      do i = 1, 10
         select case (i)
         case (:Inf)
            write (*,*) i

         case (Inf+1:)
            write (*,*) -i
         end select
      end do

      end program f

[pratikbhd]

@pratikbhd I was thinking about the "Inf" placeholder used to normalize CASE labels. Suppose the program has a variable named Inf, as shown in the program below. Would that cause a name conflict in the translation?

      program f
      implicit none
      integer i
      integer, parameter :: Inf = 5
      do i = 1, 10
         select case (i)
         case (:Inf)
            write (*,*) i

         case (Inf+1:)
            write (*,*) -i
         end select
      end do

      end program f

@skdebray I realized that the regular expression in preprocessor.py only caught numeric values in the case statement. I expanded the regular expression now to detect variables as well.

Now, the code above does not cause conflict in the translation because of the following reason:

1. During the check for Inf or -Inf in the XML, the actual Inf variable will have already been converted into lowercase and the check passes without conflict.

However, I found a bug with using write(*, *) in the Fortran code and it fails in format.py. I am using write(*, 10) for now until I fix the issue with write(*, *).

All the changed code is in the fortran_data branch.

[skdebray]

@pratikbhd Re: constants in case labels, we also need to be able to handle string and LOGICAL constants in case labels (e.g., see here). For example, the following code is from the file delphi/tests/data/program_analysis/ORIG-PETASCE.for:

     Subroutine GET_Real(ModuleName, VarName, Value)
      ...
      SELECT CASE (ModuleName)
      Case ('SPAM')
        SELECT CASE (VarName)
        Case ('AGEFAC'); Value = SAVE_data % SPAM % AGEFAC
        Case ('PG');     Value = SAVE_data % SPAM % PG
        Case ('CEF');    Value = SAVE_data % SPAM % CEF
        ...
        Case ('EVAP');   Value = SAVE_data % SPAM % EVAP
        Case DEFAULT; ERR = .TRUE.
        END SELECT
        ...

[pratikbhd]

@skdebray Strings are handled by CASE statements. I haven't extensively tested for them though. I also will have to test for LOGICAL constants.
It seems like there is a bug with WRITE(*,*) statements right now. I'm looking into fixing the bug after which I'll do the tests for the cases discussed above.

[skdebray]

@pratikbhd Let's not worry about WRITE (*,*) for now, I don't think that's critical for DSSAT. I'd rather get SELECT-CASE finished and then make progress on DATA statements.

Can you create an issue for WRITE (*,*) and assign it to me?

[pratikbhd]

@skdebray Apparently there is already an issue for this #308
I have added the current issues related to this including part of the fix I made for it yesterday in the comment section of the issue. These fixed are in the branch write_bugfix.