feat: Improved Module Support for Linting Diagnostics

[dnwillia-work]

Is there an existing request for this?

• [X] 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.

[gnikit]

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]

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.