@zedthree I am also getting lots of “M011” all of which are correct and entirely justified, but as an experiment I have included in the “only” clause a symbol that could be included legally, but which the current module does not actually use ( i.e. symbol table clutter ), and fortitude has not detected it as clutter, are there plans, is this a feature request?
1 Like
Gfortran can do this. gfortran -Werror=unused-variable xxm.f90 for
module m
integer :: i
end module m
program main
use m, only: i
print*,"hi"
end program main
gives
xxm.f90:6:4:
6 | use m, only: i
| 1
Error: Unused module variable 'i' which has been explicitly imported at (1) [-Werror=unused-variable]
f951.exe: some warnings being treated as errors
Thanks @Beliavsky and I note the same functionality is still just a feature request with IFX. This was also a feature of https://camfort.github.io/ but, alas, progress there has slowed?
On the subject of feature requests could we do the following?
fortitude check *.f90
ifx has the functionality:
$ ifx -warn unused.f90
unused.f90(6): remark #7712: This variable has not been used. [I]
use m, only: i
-------------^
Its only problem is that doesn’t distinguish between variables local to the scope and arguments, so if you’re implementing an interface (say write(formatted)), you get warnings for not using the iotype or v_list arguments.
As observed, fortitude 0.4.0 already globs this pattern and checks multiple *.f90 files present in one folder (tested in Debian 13).
Edit: My initial reply read fortitude’s checks were constrained to the current working directory. This presumption however is wrong. The call of
fortitude check
equally examines files in the sub folders.
Windows does not offer file globbing for commands not native to Windows CMD, but you can create a simple batch file to do it.
@echo off
REM Loop through all .f90 files in the current directory
for %%f in (*.f90) do (
echo Running "fortitude check" on %%f
fortitude check %%f
)
It can be saved as fortall.bat and then run with fortall.bat or just fortall.
1 Like
Complementary approach for Windows: the installation of git and subsequent tortoise Git to have a Git Bash in the dropdown of the Windows shell by MinGW. Beside the then available unix-like globbing, this equally provides goodies like grep, awk; gcc and gfortran compiler, etc. With e.g., pipx’ pipx install fortitude-lint and a pipx ensurepath, the next Git Bash started has it (as fortitude.exe), and it works well.
fortitude check by itself should find all files with the following extensions:
“f90”, “F90”, “f95”, “F95”, “f03”, “F03”, “f08”, “F08”, “f18”, “F18”, “f23”, “F23”,
(we also have a rule checking that files should actually only be .f90 or .F90)
With no arguments it recursively searches the current directory and its subdirectories. We use a cross-platform library, so this should work on linux, mac, and windows. Please raise an issue on our github if this isn’t working for you!
On the subject of additional rules, at the moment we’re not planning on targeting compile errors, aside from syntax, as generally they require more semantic information (for example, mismatched types) that we’d have to construct. If we manage to incorporate lfortran’s ASR then this would be a lot easier though.
We’re definitely planning on rules for things like unused imports, variables, and arguments though!
I am happy to implement whatever you need on the LFortran side, just let me know.
3 Likes
We’ve just released a new version, 0.5.0, mostly focused on the internals, but also making the command line and config files much nicer:
- Outputs a success message when no errors are found.
- Rules can be selected by name as well as by code, e.g.
--select=line-too-long - Entire rule categories can be toggled, either by name or by code, e.g.
--select=Tor--ignore=typing - Multiple output modes can be selected using
--output-format=full/concise/json - Fixed bugs in the config file reader, TOML errors are now propagated to the user
- Checking now occurs in parallel, giving a speed boost on larger projects
For the next version, we’re going to focus on automatic fixes and new rules. We have about 15 planned already, please feel free to open a GitHub issue for any more you’d like to see!
2 Likes
And now 0.5.1 is available, fixing a performance bug when running in parallel. On one example project with 2581 files, fortitude check has gone from 28.5s to 11.8s!
8 Likes