-
-
Notifications
You must be signed in to change notification settings - Fork 30
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
Comments
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
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 |
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. |
I tried I think it would make more sense to allow |
Is there an existing request for this?
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 modulemodule_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.
The text was updated successfully, but these errors were encountered: