Wrong use of configuration fortran.linter.compilerPath in file linter-provider.ts

[maroony]

Describe the bug
When setting this option like

"fortran.linter.compilerPath": "/usr/bin/gfortran-9",

the function getLinterExecutable() in linter-provider.ts will return this compiler path:

using linter: gfortran located in: /usr/bin/gfortran-9/gfortran

This is wrong! It has to be /usr/bin/gfortran-9. The linting feature isn't working any more.

Build info (please complete the following information):

• OS: Remote Development on Linux (SLES 12)
• Extension Version v3.0.2022042917
• Visual Studio Code Version 1.67.2

[gnikit]

This is not really a bug, the path is meant to be the rootpath of the binary, i.e. /usr/bin . The option fortran.linter.compiler is what determines the compiler to be used. Together the 2 become /usr/bin/gfortran.

There are 2 reasons why we don't allow you to just give the an arbitrary binary path:

1. It is a massive security risk to allow an extension to execute arbitrary programs on your computer (especially upon file modification)
2. There is no easy way to identify which compiler you are using i.e. gfortran or ifort (or flang and lfortran in the future)

Number 2. can be addressed by allowing you to specify the full path in fortran.linter.compilerPath and using fortran.linter.compiler to interpret the diagnostics served by the compiler. This however can lead to people using for example an Intel compiler for linting but parsing its diagnostics with gfortran, which would obviously not work.

[gnikit]

I obviously understand how this might be a bummer since not all gfortran versions have a binary alias without the version appended at the end

[maroony]

In the documentation a full path is used:

The linter executable is assumed to be found in the PATH. In order to use a different executable or if the executable can't be found in the PATH you can point the extension to another linter with the fortran.linter.compilerPath option.

{
"fortran.linter.compilerPath": "/opt/oneapi/compiler/2022.0.2/linux/bin/intel64/ifort"
}

[maroony]

When speaking of a path, usually the full string with the binary should be set. Otherwise speak of compilerDir or compilerFolder.

Compare this to maven.executable.path for example.

[gnikit]

in the README you are right it should not have ifort appended in the end of that path. I will fix it. In general, I think that I might just remove the tricks with the compiler paths and leave it up to the user to not pass unsafe binaries to the linter.

[maroony]

That's exactly what I think: Those tricks with the compiler path (here: directory) and the name are way too complicated.