Linting across files

Help Visual Studio Code
1

Hello,

I am running VS Code on Windows with the Modern Fortran extension. I have installed fortls (not fortran-language-server, but fortls). I also have the mingw toolchain with gfortran (with the correct path added to the PATH environment variable).

I have a fortran project with source code across several files (most in the same directory, but for now we can consider them all in the same directory).

Almost everything seems to work correctly “across files”, eg :

  • Autocompletion is configured to use fortls (which is the default anyway), and will correctly suggest functions that are defined/coded in another file of the project :slight_smile:
  • Hovering is configured to use fortls as well (again, the default), and hovering over a function call will correctly display an overview of how it should be called, even if said function is in another file :slight_smile:
  • Right-click->Go to Definition will open a tab and point me to the relevant code section, even if that is in another file :slight_smile:

Static syntax analysis seems to work fine for anything that can be checked inside a given file. For example, if I have a function f coded in file A.f, and somewhere else in A.f try to call f with the wrong number of arguments, the editor adequately signals an error. Great !

But if the same function f from A.f is called from another file B.f in the same directory, then the same errors won’t be caught and no error is signaled by the editor. They will only be caught and signaled for calls made inside the same physical file.

I am not sure what to do to remedy this. I have added the following to the VSCode settings.json file, but to no effect

    "fortran.linter.includePaths": [
        "${workspaceFolder}/**"
    ],
    "fortran.linter.modOutput": "${workspaceFolder}/.vscode/linter",
    "fortran.fortls.suffixes": [
        "f"
    ],
    "fortran.fortls.directories": [
        "./**"
    ],
    "fortran.fortls.preprocessor.suffixes": [
        ".f"
    ],

Would anyone know how to fix this ? Thanks for your help !

edit : if that is of any help, here is the output pane of VS Code after launching VS Code (everything seems fine I guess ?)

["INFO" - 5:57:48 PM] Extension Name: Modern Fortran
["INFO" - 5:57:48 PM] Extension Version: 3.2.0
["INFO" - 5:57:48 PM] Linter set to: gfortran
["INFO" - 5:57:48 PM] Formatter set to: findent
["INFO" - 5:57:48 PM] Autocomplete set to: fortls
["INFO" - 5:57:48 PM] Hover set to: fortls
["INFO" - 5:57:48 PM] Symbols set to: fortls
["INFO" - 5:57:48 PM] using linter: gfortran located in: D:\Logiciels\GCC\bin\gfortran.EXE
["INFO" - 5:57:48 PM] Linter.arguments:
-Wall
-ffree-line-length-none
-ffixed-line-length-none
["INFO" - 5:57:48 PM] Linter.moduleOutput: -J d:\Work\ZHCW\sources/.vscode/linter
["INFO" - 5:57:48 PM] Linter.include:
${workspaceFolder}/**
["INFO" - 5:57:48 PM] Fortran Language Server
["INFO" - 5:57:49 PM] Initialising Language Server for workspace: d:\Work\ZHCW\sources\zhcw.f with command-line options: --enable_code_actions, --autocomplete_no_prefix, --hover_signature, --use_signature_help, --lowercase_intrinsics, --nthreads=4, --incremental_sync, --disable_autoupdate, --incl_suffixes, f, --source_dirs, ./**, --pp_suffixes, .f
[INFO - 17:57:50] fortls - Fortran Language Server 2.13.0 Initialized
2

Welcome to Fortran-lang @ParkerLewis. Can you try installing the pre-release to make sure it is not related to an already fixed bug.

This will only happen if you have not compiled your project and pointed the linter to the build artifacts before hand. The linter is a wrapper around a compiler, in this case gfortran. If A.f has not been compiled, but is used in B.f then the linter will be unable to use A and fail to lint.

If that’s not the case for your and the issue is not resolved in the pre-release post a MWE for us to reproduce it.

3

Thanks @gnikit for the help.

A few additional informations since yesterday :slight_smile:

  • The behavior is stranger than what I thought. Incorrectly calling a given function from a given file sometimes adequately raises a warning, sometimes doesn’t. It depends on the file I’m making the call from and is “calling file”-dependent, ie from a given file it will always work calling f, and from another it won’t, even if neither file is where function f is coded (and all files are in the same directory).

  • Behavior is not even consistent depending on the called function (if I try with another function g, it will work where it doesn’t for f…)

  • It actually seems to stem for gfortran itself, as the compiling process itself behaves the same way (it will sometimes raise warnings, and sometimes not, based on the file the call is being made from, without any obvious explanation as to why some files are ok and some others are not), so it in fact probably isn’t linked to Modern Fortran (good for you I guess !)

  • I have compiled the project several times already, no change in behavior.

  • Still, I can’t help but notice no file is being outputed / produced in the Mod Output directory defined in Modern Fortran (the directory does exist). Is this normal ? Any idea why ?

I will also try to install the prerelease as you suggested, if only for this last issue.

Thanks for the help !

4

Hi,

So I think I have both a better understanding of why it seemed erratic (“calling file”-dependent), and I have a very trivial MWE.

Say you have two files, main.f with

      program main
      call foobar(3.,2.)
      end

and foo.f with

      subroutine foobar(a,b,c)
      real, intent(in) :: a,b
      real, intent(out) :: c
      c=a+b
      return
      end

I get no warning from the linter… or, to be fair, the compiler itself (compiling and linking issues no error or warning even with -Wall). So I guess I understand if this is no issue with fortls or the Modern Fortran extension ?

That being said, it felt weird to me because hovering the mouse over the call foobar DOES provide the correct tooltip - it DOES display the correct / expected call syntax and argument definition. So I figured that if the correct tooltip was being displayed, then surely the error in the call would be detected. I understand if both of these things are independent, although it’s a bit of a shame since being able to fetch the correct information and display the correct tooltip proves the system has everything it needs to detect the error.

[As to why it seemed “file-dependent” : that is actually because if multiple calls to the same function are being made in a given file, and they are not all consistent, then gfortran will raise a warning. So when in some files I made several calls to foo, then making a mistake in a new call was leading to warnings (possibly not where it was actually incorrect, but the discrepancy was detected). But writing the same erroneous call in another file might not raise warnings if no other call was made from the same file]

On an unrelated note, tooltips are not generated / displayed when hovering over calling an entry (even if the entry is in the same file). Maybe this is a known issue.