Getting red squiggly lines in VSCode, while saving file with .f extension

I keep getting squiggly lines in VS Code whenever I save my file with a .f extension. Even though my code runs fine, I have already installed the Modern Fortran extension but the squiggly lines persist. Here is a screenshot of the code.

is there any resolve this

1 Like

The .f extension is usually used for old-style fixed-format Fortran. Use the .f90 extension for modern (post-1990) free-format Fortran, as you are using.

3 Likes

Essentially what @DavidB said. By default VS Code associates the following file extensions to Free Form (i.e. Modern Fortran)

and these to Fixed Form

You should be able however to override default behaviour in VS Code with something like

  "files.associations": {
    "*.f": "FortranFreeForm",
  },

this is currently not working and it’s a bug in the extension’s linter, tracked here, I will try and fix it over the long weekend.

On a more general note, there’s been a quite lengthy discussion on this matter about the “correct” extensions with Fortran, you might want to read this Reclaiming `.f` file extension for modern Fortran (free form) · Issue #363 · fortran-lang/fpm · GitHub

2 Likes

Thank you @gnikit

Thanks @gnikit, and that thread is exactly why we’re starting with .f. However even for me VS Code + Modern Fortran is quite important so the fix to override the default would be very helpful if we are to continue with .f. I understand that it’s subject to your available time, of course.

2 Likes

I’ve got a patch ready. Will push and make a pre-release when I get back. In the meantime, we can manually pass -ffree-form to the extra linter args option.

Another thing I’ll have to look into is propagating this option to the language server. There’s an option specific to fortls that makes this work but I think checking and propagating the "files.associations": ... might make things easier to configure.

1 Like

@milancurcic / @rajkumardongre ,

Can you please elaborate what you’re pursuing with .f extension here? Thanks,

Given a brand new project, we have an opportunity to find out whether .f is a good choice in practice for free-form source code.

4 Likes

Brilliant! Hope you find out .f is a perfect choice!

2 Likes

Fixed in

and will be in the next automatic pre-release tonight/early tomorrow

4 Likes

Thankyou @gnikit :clap:

1 Like

Dear @gnikit ,

first of all, great work with this VS extension ! Sure it helps (A LOT) hundreds of Fortran coders using VS as the main code editor (myself in primis :slight_smile:).

As far as I understand, there is the opened discussion about making .f the default Fortran file extension, correct me if I’m wrong. Which I’d fully support.

If that’s the case, what about old (fixed form) .f FORTRAN code files mixed with Modern Fortran code .f files? In that case, should a user manually specify the form for each file present in the tree (if that’s even possible, but might be easy to add)?

Have you thought about the linter automatically infer the form by parsing the first few lines of the file content (and then store this info in some cached data somehow, for all workspace folder trees currently opened)?

Keep with it !

2 Likes

I am glad to hear that you (and the general community) find the extension useful :slight_smile: .

If that’s the case, what about old (fixed form) .f FORTRAN code files mixed with Modern Fortran code .f files? In that case, should a user manually specify the form for each file present in the tree (if that’s even possible, but might be easy to add)?

Basically, the issue here was that VS Code allows for user overrides (global/per project/per file) and we have coded the extension with that in mind. However, we did not consider that the compilers we use for linting would need to be explicitly told what type of source file we were trying to parse. That has now been fixed.

Have you thought about the linter automatically infer the form by parsing the first few lines of the file content

That is what fortls (the language server) does. It has a series of cheap heuristics when parsing sources that are only true in fixed form. For the core of the VS Code extension (i.e. outside of the language server) knowing that info before-hand would not make a difference (it needs a substantially more asynchronous approach of determining the type of language used by the file than the language server could offer).


Clarification

To be clear to all users, we are NOT changing the default behaviour of the extension, or forcing .f to be considered as free-form. We simply permit the user to override the extension’s defaults, if they choose so and have the linter, syntax highlighting and language server, work as expected.

3 Likes