bug(linter): GFortran 4.x.x support

[linyc253]

Type: Bug

The linter of Modern Fortran cannot work when I use ssh remote extension to connet to my server.

SYSTEM Local - Windows 10 Remote server - CentOS 7

STEP

1. Install gcc, gcc-fortran using yum package manager
2. Follow the guideline of 'ssh remote extension' to connect my vscode to my server (CentOS)
3. Install C/C++, Modern Fortran extension on server

RESULT Most of the function (coloring etc...) work well, but the linter (detect the error or warning and show in the 'PROBLEM' log, using gfortran compiler) is not. No error shown even if I type a wrong line in my code.

More information:

1. The linter for C language work, so I guess the problem occur at Modern Fortran extension
2. In my local machine, I use Cygwin as terminal in VScode, and the linter work well
3. I've tried to reinstall different version of 'Modern Fortran', none of them work
4. In settings.json, I set -- "fortran.linter.compiler": "gfortran"
5. fortls has been properly install
6. Someone had report the same issue before, but did not receive reply: https://github.com/microsoft/vscode-remote-release/issues/1121

Extension version: 3.2.0 VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:59:02.252Z) OS version: Windows_NT x64 10.0.19044 Modes: Sandboxed: No Remote OS version: Linux x64 3.10.0-1160.81.1.el7.x86_64

[gnikit]

That is weird, extensions don't do anything special when launched from a remote client. That is really the whole appeal of remote SSH, regardless can you try the following:

1. Can you install the pre-release? Set the verbosity to Debug and post the log output from the linter.
2. Open a terminal on your remote SSH (through your vscode session) and run gfortran -fsyntax-only yourfile.f90. if that doesn't work then your permissions or gfortran on the remote machine have some issue.

[linyc253]

1. Is this what you refer to? (I've reloaded vscode windows)

2. There's no problem =====Edited===== Please ignore the "./a.out" in terminal in the snapshot above (this file had been compiled previously)

For code with error

[linyc253]

Oh, I got the problem. It's my GNU Fortran compiler.

But I still cannot solve it because yum say that I've updated to lastest version. Do I need to manually install other version of gfortran compiler?

[gnikit]

That seems to indicate something wrong with the version checking of your compiler, which is weird (given that we can see it). Can you post the entire screenshot of the log output when you try to lint a file with a mistake in it?

Also can you run the terminal command for that file too? This old versions of gfortran have multiple bugs and features missing, so it's very likely we are doing something that is not backwards compatible with gfortran 4

[linyc253]

Here's the full screenshot: As for the terminal command for that file, I had post it on the last post in "Edited" part.

Here's my another try to solve the problem: I just modify the code in "mypath/fortran-lang.linter-gfortran-3.4.2023013101/dist/extension.js" (in my server) From /^GNU Fortran \([\S ]+\) (?<version>.*)$/gm (I found it at 102 line of "linter-provider.ts") To /^GNU Fortran \([\S ]+\) (?<version>\S+)/gm So as to avoid the string matched to invalid form (4.8.5 20150623 (Red Hat 4.8.5-44) instead of 4.8.5) However, although this solve the error with version checking, the linter is still not working. The new log output is as follow

[gnikit]

You're right, the regex expression is not generic enough. I'll fix that today and it should be available in tomorrow's pre-release version.

[gnikit]

I haven't had time to work on this today. I need to rethink the version mechanism (it's not just the regex that's the issue) and make it more robust to these non semver versions of gfortran.

[linyc253]

Two things, first is that in the new version v3.4.2023020101, regex problem is not fixed yet, so currently I'm still using the version I modified yesterday. Just in case you need this, my output of gfortran --version is GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) Copyright (C) 2015 Free Software Foundation, Inc. ` GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING`

Second, I found some mistake in my path setting, after I correct this, the output log indeed show that the linter can detect the error correctly. However, there's still nothing in "Problem" console, and neither the red underline appear in my code.

[gnikit]

From what I can tell from the very last screenshot you uploaded the linter does indeed capture the compiler error. I can't see anything wrong with the logs. I suspect you might have to close and reopen vscode to get this to work.

BTW I have fixed the regex expression to account for the edge cases of GNU where you have X.X.X something and also update the messages displayed. The extension should not be throwing an error there since in case something goes wrong the linter falls back to the default GFortran options. The version check is only present to pass arguments to GFortran linter that are not backwards compatible.

I can't think of an SSH specific reason as to why the extension would not be working.

Let me know if the issue has been resolved so that I can close the issue.

[linyc253]

The bad news is that the problem is still unsolved even after I reinstall all the vscode related stuff in my remote server, and I have no idea what's going wrong.

The only info I can provide is that in my local computer (with pre-release version installed), which can run the linter correctly, the log looks like:

As contrast, in my remote server, the log Notice that in the last line, they are different. Local computer has f951.exe: at the beginning of the line, while remote server do not. Will this make a difference?

[gnikit]

Both logs look fine to me. The "Errors" are not extension errors but the output of gfortran. As for f95.exe that's just gfortran saying that it encountered a Fatal Error.

Can you share your remote settings too please?

All this is rather strange, it's as if the part of the linter responsible for creating the vscode diagnostics does not see the compiler output.

I will add some more logs to the extension to trace this. If I upload here a .vsix file (it will contain all the logs that we might not want to include in an official pre-release) for the extension would you be able to install it in your remote?

[linyc253]

Here's some of my settings, I'm not sure whether these are what you need.

{
    "workbench.colorTheme": "Default Dark+",
    "editor.minimap.enabled": false,
    "workbench.editor.untitled.hint": "hidden",
    "window.commandCenter": true,
    "files.autoSave": "afterDelay",
    "remote.SSH.configFile": "D:\\Linux\\ssh_config\\fig",
    "remote.SSH.remotePlatform": {
        "140.113.49.26": "linux",
        "server.oldgrandpa(out)": "linux"
    },
    "fortran.fortls.path": "/home/linyc253/.local/bin/fortls",
    "fortran-ls.executablePath": "/home/linyc253/.local/bin/fortls",
    "fortran-ls.autocompletePrefix": true,
    "fortran-ls.lowercaseIntrinsics": true,
    "settingsSync.ignoredExtensions": [

    ]
}

As for the .vsix file, I think I should be able to install it.

[gnikit]

Okay, @linyc253 I have just released a pre-release with additional log messages, this should hopefully help narrow down what's going on.

From the log messages you've posted we can tell that your remote session's compiler works and produces valid output.

[linyc253]

Here's the log

The upper half is for a file without error, and lower half for a file with error.

[gnikit]

I just realised what the issue is. The error being reported uses a . instead of : to indicate the column number. That must be an old syntax from GCC. Upon further investigation it appears that in v5+ GFortran starting using : instead of ..

I will fix it right away and issue a pre-relese.

[linyc253]

Hi, I think the bug is still unsolved, even after installing the latest version of extension. And the log looks the same as before

Currently I've jump over this bug by upgrading my gfortran compiler to version 7.3.1. So basically the problem has been solved, for me. But if you're still interesting in this issue, I haven't remove the old version gfortran, so I can do the test if needed.