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

feat: Improved Module Support for Linting Diagnostics #990

Open
1 task done
dnwillia-work opened this issue Sep 20, 2023 · 3 comments
Open
1 task done

feat: Improved Module Support for Linting Diagnostics #990

dnwillia-work opened this issue Sep 20, 2023 · 3 comments

Comments

@dnwillia-work
Copy link

Is there an existing request for this?

  • I have searched the existing issues

Feature Request

In issue #175 I requested the ability to control where the Fortran modules are placed and this has since been added, which is great. However, you might note this comment.

This is still the behaviour today. In order to get rid of the red squiggles on the use module_name statements you have to go and load the code that contains the module module_name so that the .mod file is generated into the output directory. It's working but you need to click on them one by one.

It would be much better if the .mod files are generated on the fly when you load a particular source file.

This is an issue on both Windows, when configured with Intel Fortran, and Linux/MacOS when configured with gfortran.

@dnwillia-work dnwillia-work changed the title feat: Improved .mod generation for Fortran Intellisense feat: Improved Module Support for Fortran Intellisense Sep 20, 2023
@gnikit
Copy link
Member

gnikit commented Sep 20, 2023

This is essentially a build system request, which would be very useful. A basic attempt to solve this has been added to the pre-release which I would strongly advise you to try. The option is under the linter settings fortran.linter.initialize. A better solution would involve using `

  • fpm` to get the file order with which files should be linted and then run through the vscode linter
  • get fpm to generate the .mod files and emit any possible warnings
  • write/or use an existing dependency graph generator, and query the nodes (corresponding to a source file) to generate linting messages

All three are not that simple to implement, especially since vscode does not have an elegant way of opening and closing files.

The only realistic solution, if working on a very large project is to build the project a-priori and then point the linter to the location of the .mod files.

@gnikit
Copy link
Member

gnikit commented Sep 20, 2023

I think this won't make it in the next release, which has been finished but remained in a pre-release stage for some time now, but I would like to include it in the next year's roadmap.

@gnikit gnikit changed the title feat: Improved Module Support for Fortran Intellisense feat: Improved Module Support for Linting Diagnostics Sep 20, 2023
@phil-blain
Copy link

I tried fortran.linter.initialize but it tries to lint all workspace files in the order it receives them from getFiles, so in a large project all these linter invocation mostly fail because Fortran modules must be compiled in a specific order.

I think it would make more sense to allow fortran.linter.initialize to point to a specific VSCode task. This way the task could precompile the project such that all modules are created in the correct order. This was suggested in #175 (comment).

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

No branches or pull requests

3 participants