Fortran f90 grammar: problems parsing END SELECT

[suehshtri]

I've been looking at this and looked at the Fortran90parser.g4 and am just not seeing the problem. It looks like a END SELECT NAME? should be ok with this.

Example Fortran code that works with gfortran -c -std=f95 subroutinepain.f90

module mymodule
  implicit none
  contains
  subroutine my_sub(arga, argb, argc)
    integer :: arga
    integer :: argb
    integer :: argc
    integer :: test1

    select case (arga)
    case (31)
      test1 = 1 + 2
    case (42)
      test1 = 4 + 2
    end select
  end subroutine
end module

line 17:0 missing NAME at 'end'
line 18:0 no viable alternative at input 'module\n'

The preview also starts complaining at line 4 at the LPAREN: (12,6) no viable alternative input

[kaby76]

... preview ...

What "preview"?

[suehshtri]

... preview ...

What "preview"?

The preview pane in the ANTLR tool from the ANTLR plugin in IDEA.

[kaby76]

The Intellij IDEA Antlr4 plugin "ANTLR Preview" pane uses the "interpreter" form of the parsing engine. It does not use a compiled parser. The tool should warn whether there are actions in the grammar, which are in the fortran90 grammar, and that the interpreting parser may not parse correctly. The fortran90 grammar cannot be "interpreted" in most situations. https://github.com/antlr/intellij-plugin-v4/issues/487#issuecomment-976338931 . What's annoying is that one cannot even "test" if you don't "generate" the parser code, which is really misleading because you think you are generating .java code, then compiling to .class'es--but you're not. "generate" only parses the grammar, constructing a parse tree, which is then "interpreted", and as a side-effect creating .java code. In fact, using the "generate" as part of a build process is just completely wrong in so many ways.

[suehshtri]

sure enough, the example code is parsed fine by the generated C# parser. -sigh- The example code is inspired by some code I can't share. I will add some more code to it until I get an example that replicates what I am seeing and post a better example to the ticket.

[suehshtri]

Looks like I have a problem with use, intrinsic :: iso_c_binding.

module mymodule
  implicit none
  contains
  subroutine my_sub(arga, argb, argc)
    !--- use, only : parameters
    use somemodule, only : somefunc

    !---use standard modules
    use, intrinsic :: iso_c_binding

    integer :: arga !< 1
    integer :: argb !< 2
    integer :: argc !< 3
    integer :: test1

    if (arga .gt. -3) then
      select case (arga)
      case (31)
        test1 = 1 + 2
      case (42)
        test1 = 4 + 2
      end select
    endif
  end subroutine
end module

If I pass the std=f95 option to gfortran it does complain, but if I leave it off, it does not. Error: Fortran 2003: module nature in USE statement at (1)

[kaby76]

Well, for use, intrinsic :: iso_c_binding, this should be parsed via useStmt.

https://github.com/antlr/grammars-v4/blob/d097b980814458029a14f277e582eaba90f9e710/fortran/fortran90/Fortran90Parser.g4#L85-L89

The prelim '90 Spec https://wg5-fortran.org/N001-N1100/N692.pdf doesn't have any alt with ::, but the 2018 Spec does. https://j3-fortran.org/doc/year/18/18-007r1.pdf.

Unless we have the official specs in hand, it's hard to say what actually should be the grammar for Fortran '90. I thought I have the official specs, but it will take some time to find them on my machine.

[suehshtri]

@kaby76 , it has surprised me how hard they make it to dig up the specs, and I think it does hinder creating tooling for the language.

Thank you, by the way, for the time and effort you put into the grammar.

[kaby76]

I now have a copy of the official spec for F2023. I think the way to proceed is to skip F90/95, and just create a new Antlr grammar for F2023 using the spec with the old grammar as a basis.