Error messages about "USE/variable in source file" -
I am trying to use FORD on one of our programs. The source code consists of some 20 files, nothing really large and I thought it was a good test before I would attempt FORD on the whole suite. However, I run into bizarre problems and I have not been able to create a small example that exhibits the same phenomena.
What happens is that FORD complains about a USE statement:
Reading file src\agr_hyd_step.f
Traceback (most recent call last):
File "c:\users\markus\.julia\conda\3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
...
Exception: Found USE statemnt in SOURCEFILE
When I comment out the USE statements (there are actually two), I get:
Reading file src\agr_hyd_step.f
Traceback (most recent call last):
File "c:\users\markus\.julia\conda\3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
...
Exception: Found variable in SOURCEFILE
The module is not included in the source tree in which I do the experiment, but that should not matter because I have defined that as an “extra_mod” in the project file. And furthermore I do not see any evidence of FORD first scanning all the source files for module definitions.
I even tried putting a dummy module in the source file, so that it would surely be found, but that does not help in any way either.
It is unclear whether this is due to the fixed-form of the source file or not, as others have been read without a problem. If it helps, I have attached the file in question. agr_hyd_step.f.txt
I found the cause: the file in question contains source lines longer than 72 characters. The error messages are simply misleading.
There are three ways to deal with this:
- set
fixed_length_limit: falseto ignore the 72-character limit - rename the file to
agr_hyd_step.f90so that FORD parses it as free form (the file is already using Fortran 90 features, so this shouldn't be a problem for your compiler) - change how the extensions are parsed with
extensions/fixed_extensions-- if you have other.ffiles that really are fixed form, you probably don't want to do this though
Hope that helps!
Unfortunately, FORD's parsing error messages are not great because we don't track the original location. It's something I'd like to fix though!
Ah, thanks! I checked the result by manually dealing with the long lines, but this is much better :).
The first option is most probably the easiest. We have a code base that contains a lot of fixed-form source files, even though the code itself has undergone many modernisations over the years. So, renaming to .f90 may clash with line continuations, for instance.
O, that did not do the job :(. I get the same error message.
I am using version 6.0.0 if that matters.
I don't think we've fixed any bugs relating to this since then, but you still probably want to upgrade to the latest version, 6.1.16 -- we've fixed lots of other bugs!
For reference, here's how I'm using option 1 to get it to work by changing the example project file:
modified example/example-project-file.md
@@ -28,6 +28,7 @@ extra_filetypes: sh #
max_frontpage_items: 4
exclude: excluded_file.f90
exclude_dir: src/excluded_directory
+fixed_length_limit: false
---
Hi, my name is ${USER}.
and I've put your file under example/src:
example/src/
├── agr_hyd_step.f
├── excluded_directory
│ └── this_file_will_not_be_included.f90
├── excluded_file.f90
├── ford_example_type.f90
├── ford_test_module.fpp
└── ford_test_program.f90
Hm, worth checking it out then (I installed FORD via Anaconda). Will keep you posted.
Okay, I updated my installation to version to 6.1.16. This did change the error messages, but with or without the fixed_length_limit keyword the results are the same:
Reading file src2\agr_hyd_step.f ERROR in file 'agr_hyd_step.f': Unexpected USE statement in sourcefile 'agr_hyd_step.f': use hydmod ERROR in file 'agr_hyd_step.f': Unexpected variable in sourcefile 'agr_hyd_step.f': type(t_hyd) :: input_hyd ERROR in file 'agr_hyd_step.f': Unexpected variable in sourcefile 'agr_hyd_step.f': integer :: ipnt(*) ...
If I correct the first line in the source file that is too long, I do get the intended documentation. The file contains several long lines, but the others are long because of a concatenation of statements. But a bit of experimentation showed that the problem is the subroutine header, not long lines per se.
It's odd that fixed_length_limit doesn't fix it for you. I'm not sure what could cause that. Any chance you could upload your Ford project file?
Sure, I have reduced it to just about the smallest collection of files that exhibits the problem. Perhaps I have made a mistake in the keywords, but I know thst if I wrap the subroutine header and leave all the other lines as is, it does work
Regards,
Arjen
Op di 11 okt. 2022 om 12:53 schreef Peter Hill @.***>:
It's odd that fixed_length_limit doesn't fix it for you. I'm not sure what could cause that. Any chance you could upload your Ford project file?
— Reply to this email directly, view it on GitHub https://github.com/Fortran-FOSS-Programmers/ford/issues/455#issuecomment-1274497421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN6YR5HLVHTEWJAXHWKOQLWCVBJHANCNFSM6AAAAAAQ7T4K2E . You are receiving this because you authored the thread.Message ID: @.***>