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): GFortran 4.x.x support #813

Closed
linyc253 opened this issue Jan 31, 2023 · 16 comments · Fixed by #823
Closed

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

linyc253 opened this issue Jan 31, 2023 · 16 comments · Fixed by #823
Assignees
Labels

Comments

@linyc253
Copy link

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:
    Fortran syntax error checking is not working in Remote ssh microsoft/vscode-remote-release#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
Copy link
Member

gnikit commented Jan 31, 2023

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
Copy link
Author

linyc253 commented Jan 31, 2023

  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
Copy link
Author

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
Copy link
Member

gnikit commented Jan 31, 2023

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
Copy link
Author

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
Copy link
Member

gnikit commented Jan 31, 2023

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
Copy link
Member

gnikit commented Feb 1, 2023

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
Copy link
Author

linyc253 commented Feb 1, 2023

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 gnikit self-assigned this Feb 1, 2023
@gnikit gnikit added the bug label Feb 1, 2023
@gnikit
Copy link
Member

gnikit commented Feb 2, 2023

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
Copy link
Author

linyc253 commented Feb 2, 2023

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
Copy link
Member

gnikit commented Feb 2, 2023

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?

@gnikit gnikit reopened this Feb 2, 2023
@linyc253
Copy link
Author

linyc253 commented Feb 2, 2023

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
Copy link
Member

gnikit commented Feb 5, 2023

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
Copy link
Author

linyc253 commented Feb 5, 2023

Here's the log
圖片

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

@gnikit
Copy link
Member

gnikit commented Feb 5, 2023

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.

@gnikit gnikit changed the title Linter not working in Modern Fortran when using ssh remote bug(linter): GFortran 4.x.x support Feb 5, 2023
@linyc253
Copy link
Author

linyc253 commented Feb 8, 2023

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.

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

Successfully merging a pull request may close this issue.

2 participants