Anybody out there using VS Code + Modern Fortran extension + Ifort/Ifx on Windows?

Help
1

Originally posted on Intel Communities - Intel Fortran Compiler (Intel® Fortran Compiler - Intel Communities)

As the question suggests, I have been setting up Visual Studio Code with the Modern Fortran extension to use ifort on Windows and have had a few issues. The repo I’m working with contains two major VS 2019 solutions, consisting of several Fortran, C/C++ and CUDA projects (some of which are in both solutions). There are some other solutions present too: test harnesses and utilities, which I’m not worried about for the time being. Our projects put output and intermediate files in (ConfigurationName).(PlatformName), hence the Debug.x64 below. This is my current .vscode/settings.json for the repo:

{
    "cmake.configureOnOpen": false,
    "fortran.linter.compiler": "ifort",
    "fortran.linter.modOutput": "${fileDirname}/Debug.x64",
    "fortran.linter.extraArgs": [
        "/module:Debug.x64",
        "/I${env:IFORT_COMPILER21}compiler/include/intel64",
        "/I${workspaceFolder}/cs/iwpps/Debug.x64",
        "/I${workspaceFolder}/cs/simlib/Debug.x64",
        "/I${workspaceFolder}/ws/wneng_lib/Debug.x64",
        "/I${workspaceFolder}/ws/wspp_lib/Debug.x64",
        "/I${workspaceFolder}/infoworks_2d/iw_2d_sim/Lib1/Debug.x64",
        "/I${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_simlib/Debug.x64",
        "/I${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_siml1D/Debug.x64",
        "/I${workspaceFolder}/cs/iwsimstate/Debug.x64",
        "/I${workspaceFolder}/cs/tscal_lib/Debug.x64",
        "/I${workspaceFolder}/cs/swmm5_c_binding/Debug.x64",
        "/I${workspaceFolder}/cs/sim/Debug.x64"
    ],
    "fortran.linter.includePaths": [
        "${env:IFORT_COMPILER21}compiler/include/**",
        "${workspaceFolder}/cs/iwpps/**",
        "${workspaceFolder}/cs/simlib/**",
        "${workspaceFolder}/ws/wneng_lib/**",
        "${workspaceFolder}/ws/wspp_lib/**",
        "${workspaceFolder}/infoworks_2d/iw_2d_sim/Lib1/**",
        "${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_simlib/**",
        "${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_sim1D/**",
        "${workspaceFolder}/cs/iwsimstate/**",
        "${workspaceFolder}/cs/tscal_lib/**",
        "${workspaceFolder}/cs/swmm5_c_binding/**",
        "${workspaceFolder}/cs/sim/**"
],
"fortran.fortls.preprocessor.suffixes": [
    ".f90",
    ".F90"
],
"fortran.fortls.preprocessor.directories": [
    "${env:IFORT_COMPILER21}compiler/include",
    "${env:IFORT_COMPILER21}compiler/include/intel64"
],
"fortran.fortls.directories": [
    "${env:IFORT_COMPILER21}compiler/include",
    "${env:IFORT_COMPILER21}compiler/include/intel64",
    "${workspaceFolder}/cs/iwpps",
    "${workspaceFolder}/cs/simlib",
    "${workspaceFolder}/ws/wneng_lib",
    "${workspaceFolder}/ws/wspp_lib",
    "${workspaceFolder}/infoworks_2d/iw_2d_sim/Lib1",
    "${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_simlib",
    "${workspaceFolder}/infoworks_2d/iw_2d_sim/iw2d_sim1D",
    "${workspaceFolder}/cs/iwsimstate",
    "${workspaceFolder}/cs/tscal_lib",
    "${workspaceFolder}/cs/swmm5_c_binding",
    "${workspaceFolder}/cs/sim"
],
"fortran.fortls.disableDiagnostics": false
}
  1. I’m not convinced that adding the module directories to the linter extra arguments is the way to go, but the “standard” way seems to require me to open any dependencies before opening the file of interest to find objects in them.
  2. I’m not convinced all of these options support $(env:), but then I’m not sure what escape characters, if any, I would need for an explicit path for the compiler (i.e "C:\Program Files (x86)\Intel\oneAPI\compiler\2022.0.0\windows")
    3.As a consequence of 2 (?), compiler supplied modules like ifwin are showing up as not found: “Module “ifwin” not found in project”, “#6580: Name in only-list does not exist or is not accessible. [BOOL]”.
    4.Perhaps I should be using globs instead of long lists of paths?
2

Hi @Mark_Lewy

So that is true, and we have plans of fixing that in the future, probably in v4.0. Currently, how it’s meant to work is

  1. you build/compile your project first
  2. Point Modern Fortran to the locations of the .mod files using "fortran.linter.includePaths"
  3. Output the mod files generated from Modern Fortran’s linter to another location outside of your build using "fortran.linter.modOutput"

If you are unable to do that you will have to do what you mentioned; open the deps one by one until you create all the needed .mod files (steps 2. and optionally 3. are still needed).

The solution we have thought off is running an initialisation step, like in C++, where we produce the .mod, .smod files for all detected Fortran files in your project and stash them in a VS Code cache location.

I am not sure either, the variable resolution for env is present but I am not sure if it does what it’s meant to. Specifically, it can only resolve variables from your parent shell, see line 216. We would be able to resolve variables from other extensions if we were passing additionalEnvironment when we used the function for variable resolution, but past me was lazy and thought this is a problem for future me…

For Windows path separators, many combinations work. I often see users using the \\ e.g.

"fortran.formatting.fprettifyArgs": ["-c", "C:\\Users\\mreno\\fprettify.yaml"],

I would try globs first, but remember dir/** will match all directories inside dir/ BUT NOT dir/ itself, so you have to add that manually.

One more thing I noticed, is that you use /I to include paths, in the background the extension uses -I. I am not sure what is correct for ifort/ifx. It might be that the extension is erroneously using on Windows -I instead of /I, I will have to spin up a VM to test that since I don’t use Windows.

3

Thanks @gnikit, I’ll try out your suggestions and see what happens.

BTW, the ifort driver on WIndows doesn’t mind if you use /I or -I for include paths. There are some other options, however, where the Windows and Linux option names differ, but I suspect these wouldn’t be relevant for code in vscode-fortran-support.

One other fly in the ointment is that the two main solutions in ws and cs contain modules with the same names. I think the easiest way to resolve this is to have separate VS Code configuations in each folder, rather than one in the repo root.

4

You might want to check multi-root workspaces see Multi-root Workspaces in Visual Studio Code, the language server should work fine. I am not sure if the linter will