Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Linter errors from include files reported in main file #931

Open
1 task done
albertziegenhagel opened this issue Jun 27, 2023 · 4 comments
Open
1 task done
Labels

Comments

@albertziegenhagel
Copy link
Contributor

albertziegenhagel commented Jun 27, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Description

If a fortran file A includes another file B, and the file that is included (B) has a syntax error in it, the linter errors (I am using gfortran) are incorrectly reported to be in the file A.

As an example let file A be prog.f90 with

! Meaningless comment
! to make the error
! more visible
program prog
  implicit none
  include 'include.inc'

  print*, "Hello Include!"
end program prog

and file B is include.inc with

integers :: i

(note that there is a typo: integers instead of integer).

Here the linter error is reported in prog.f90 line 2, column 9 but in fact, it is in include.inc.

If I copy the gfortran command from the Modern Fortran output window to a terminal and invoke gfortran manually it reports

include.inc:2:8:

Error: Malformed type-spec at (1)

Screenshots

image

Expected Behaviour

That is actually not that easy to answer. One solution would be to report the errors in the include.inc file, but this could lead to problems when the file is included from multiple locations and each inclusion leads to different errors (as an example, one can fix the typo in the include.inc file above, but add -Wunused-variable to the linter arguments. In this case one will get a warning about an used variable i in the example. But if we would include the same file from another subroutine where i is used, this will not trigger a warning).

An alternative would be to show all warnings from the includes on the include 'include.inc' line in prog.f90, but this way one might get a lot of warnings/errors in that single line and it will be hard to figure out where exactly they originate from.

I am open for any other suggestions for solutions to that problem

Version of Modern Fortran

v3.4.2023062602

Version of Visual Studio Code

1.79.2

Platform and Architecture

Windows

Additional Information

No response

@gnikit
Copy link
Member

gnikit commented Jun 27, 2023

Hey @albertziegenhagel thanks for the issue. Can you set the language type of the .inc file to FreeFormFortran and see if there's a difference?

I suspect that the file URI for the .inc file is not "registered" via our extension.

Also, gfortran version are you using?

@albertziegenhagel
Copy link
Contributor Author

The language type was already set to FreeFormFortran. But even if I rename the file to include.f90 the error still exists (although in that case I do additionally get the error displayed in the include.f90 file.

I am running gfortran 13.1.0:

PS C:\> gfortran --version
GNU Fortran (Rev6, Built by MSYS2 project) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@albertziegenhagel
Copy link
Contributor Author

I would say the issue is that in compilers.ts#L144-L163 the fname from the match is simply ignored and then in provider.ts#L329-L350 all errors are reported in document.uri, which is the file the linter was invoked on (here prog.f90). This seems to be the case for all linters, not only gfortran.

@gnikit
Copy link
Member

gnikit commented Jun 27, 2023

Yes that is correct. The problem is that diagnostics should be created/destroyed when a file is opened/closed.

We can't serve diagnostics to a file that has not been opened yet. In your case, you have opened the .inc file and consequently the error manifests as
"Diagnostics in the wrong file".

If the .inc file had not been opened, I think the expected behaviour would be to show no errors/warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants