Erroneous syntax highlighting, when argument is called "function" or "procedure"

[gnikit]

This is another edge case that the TextMate bundle did not account for. Some keywords should be escaped as when not matching their normal regex pattern.

  interface set_scalar_field_from_python
    module procedure set_scalar_field_from_python_sp

    subroutine set_scalar_field_from_python(function, function_len, dim, &
         nodes, x, y, z, t, result, stat)
      use iso_c_binding, only: c_double, c_int, c_char
      implicit none
      integer(c_int), intent(in), value :: function_len
      character(kind=c_char, len=function_len) :: function
      integer(c_int), intent(in), value :: dim, nodes
      real(c_double), dimension(nodes), intent(in) :: x, y, z
      real(c_double), intent(in), value :: t
      real(c_double), dimension(nodes), intent(out) :: result
      integer(c_int), intent(out) :: stat
    end subroutine set_scalar_field_from_python
  end interface set_scalar_field_from_python

[pedro-ricardo]

Hello, please check if adding the ^\\s* in the begin variable in function-definition scope as below solves your issue

In here

"function-definition": {
    "comment": "Funtion program unit. Introduced in the Fortran 1977 standard.",
    "name": "meta.function.fortran",
    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*\\bfunction\\b)",
    "end": "(?=[;!\\n])",

Change

    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*\\bfunction\\b)",

To

    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*^\\s*\\bfunction\\b)",

If it works, please consider adding the same fix to subroutine-definition in the same PR.

[gnikit]

@pedro-ricardo Do you know if we can somehow unittest the syntax highlighting? I fear that in fixing one thing we might break another

[pedro-ricardo]

When debugging the highlights I use the editor.action.inspectTMScopes to check if the word is in the correct scope and if not why it ended in a different scope.
So I suppose it is possible to create an example file, just like the one used in the symbol check, that will verify if the words are in the scope they should.

But since I've only changed the regex stuff in the extension so far, I have no knowledge of how the typescript files work inside it.

Maybe you should create another issue with this feature request. When this background of the test is done I imagine that it will be easier to add more and more cases for it to check.

[gnikit]

Hello, please check if adding the ^\\s* in the begin variable in function-definition scope as below solves your issue

In here

"function-definition": {
    "comment": "Funtion program unit. Introduced in the Fortran 1977 standard.",
    "name": "meta.function.fortran",
    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*\\bfunction\\b)",
    "end": "(?=[;!\\n])",

Change

    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*\\bfunction\\b)",

To

    "begin": "(?i)(?=([^'\";!\\n](?!\\bend))*^\\s*\\bfunction\\b)",

If it works, please consider adding the same fix to subroutine-definition in the same PR.

I think I might need to do some more work at escaping keywords because character(kind=c_char, len=function_len) :: function still seems to be wrong. I will have a look.

[gnikit]

So this is actually way more annoying than it looks.
We need to escape keyword.other.function.fortran scope for when we have :: or ( + any and all whitespaces that follow.
so something like this (?<!::\\s*) should cover the ::, however, lookbehinds need to be of fixed width so theoretically we can't use *. It would appear that the VSCode regex can handle variable width negative look-behinds, so this fixes the :: issue.

We are still left with subroutine name( function ). That one gets highlighted red by meta.attribute-list.fortran. We need to make the begin expression more greedy. We could achieve this by doing a no capture on ( and all whitespaces that follow.

"begin": "(?i)(?=([^'\";!\\n](?!\\bend))*(?:(?<!\\(\\s*))\\bfunction\\b)",

This is actually a lot more work since we should technically be able to escape all of Fortran keywords e.g. function, subroutine, module, submodule, procedure, contains,...

Also, the solution I have created does not solve the problem the right way. Instead of placing the variables in meta.parameter.fortran it places them in meta.function.fortran. Thankfully the input arguments in the input arg list are captured correctly in variable.parameter.fortran

[gnikit]

This has now been fixed. The solution was a bit more involved than what I originally stated but should be okay now.