Procedures containing coarrays lead to "keyword not found in argument list"

[han190]

Describe the bug
As the title describes, procedures that has a coarray as an argument will trigger

Variable "coarray[:]" with INTENT keyword not found in argument list

To Reproduce
The MRE is as follows

program main
  implicit none
contains
  subroutine co_routine(coarray)
    real, allocatable, intent(inout) :: coarray[:]
  end subroutine co_routine
end program main

Screenshots & Animations

Additional context
Apparently the line
https://github.com/gnikit/fortls/blob/df2e41708e9b0b8f9e287ab0d06e070fb19182c0/fortls/objects.py#L1008
is triggered. I guess the square brackets are considered as part of the variable and therefore "not found" when comparing with the argument list of the procedure.

[gnikit]

Hi @han190 I have been meaning to add coarray support for a while but the thing stopping me is that it is tied to other parsing related bugs. It ultimately comes down to the need of having to parse and store "implicitly" defined variables (not to be confused with the Fortran use of the word implicit) like call foo(2.0), as it currently stands, the 2.0 is ignored by the parser.
In a very annoying and complicated way that problem also ropes in the coarrays, passing array slices as arguments, associate blocks and many others. This is just a small list of the bugs that stem from this

• Parse Fortran Literals as AST Variable/Constant nodes #125
• Parameter values not captured robustly #124
• Hover in ASSOCIATE blocks with array slices #108
• Signature help with nested parentheses displays wrong argument from argument list #87

Ultimately, I think I might just do the individual fixes and if I ever find the time or the funding, I will rewrite the parser, which would resolve all them in a much cleaner way.

[han190]

Hi, @gnikit. I didn't realize the issue is related to a deeper problem. And yes, a rewrite of a Fortran parser is definitely a much cleaner way to wipe all these issues once for all. But this is far beyond and should not be an enthusiast's distribution, this project should be funded if Fortran users really want a full-fledged Fortran parser.

For now, I will just report as many issues as I can (for this and other related projects, like the VSCode Fortran extension) and try my best to help locating those issues.

Thank you again for your selfless contributions!

[gnikit]

I didn't realize the issue is related to a deeper problem.

It unfortunately falls in the vague category of problems of how do I detect (on the fly) where a variable name ends and an attribute to the variable begins.

But this is far beyond and should not be an enthusiast's distribution, this project should be funded if Fortran users really want a full-fledged Fortran parser.

I hear you, but because I decided to setup fortls as an open-source project that requires basically no technical support any companies/governmental agencies/labs that are using it for their work have no reason to pay, and I can't really blame them. I chose to keep the project open-source knowing that this was the most probable outcome.

I registered fortls with Tidelift, but it's unlikely that any funding will come from them, since they relatively small and generate their revenue only from enterprise clients.

On the bright side, @certik is doing some amazing work with lfortran/lpython, including creating a language server using the substantially more robust lfortran parser. I also chime in to their language server project from time to time to see if I can help, but with or without me, I would guess in 1-2y from now they should have a good language server, effectively making fortls obsolete!

For now, I will just report as many issues as I can (for this and other related projects, like the VSCode Fortran extension) and try my best to help locating those issues.

Thanks that's very valuable, the unittests are only as good as my imagination, so needless to say I miss a lot of things...