Fortran f90 grammar: problems parsing END SELECT
suehshtri opened this issue · comments
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
... preview ...
What "preview"?
... preview ...
What "preview"?
The preview pane in the ANTLR tool from the ANTLR plugin in IDEA.
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. antlr/intellij-plugin-v4#487 (comment) . 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.
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.
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)
Well, for use, intrinsic :: iso_c_binding
, this should be parsed via useStmt
.
grammars-v4/fortran/fortran90/Fortran90Parser.g4
Lines 85 to 89 in d097b98
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.
@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.
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.