ford icon indicating copy to clipboard operation
ford copied to clipboard

Error messages about "USE/variable in source file" -

Open arjenmarkus opened this issue 3 years ago • 10 comments

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

arjenmarkus avatar Oct 07 '22 13:10 arjenmarkus

I found the cause: the file in question contains source lines longer than 72 characters. The error messages are simply misleading.

arjenmarkus avatar Oct 07 '22 14:10 arjenmarkus

There are three ways to deal with this:

  1. set fixed_length_limit: false to ignore the 72-character limit
  2. rename the file to agr_hyd_step.f90 so 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)
  3. change how the extensions are parsed with extensions/fixed_extensions -- if you have other .f files 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!

ZedThree avatar Oct 07 '22 15:10 ZedThree

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.

arjenmarkus avatar Oct 07 '22 15:10 arjenmarkus

O, that did not do the job :(. I get the same error message.

arjenmarkus avatar Oct 07 '22 15:10 arjenmarkus

I am using version 6.0.0 if that matters.

arjenmarkus avatar Oct 07 '22 15:10 arjenmarkus

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

ZedThree avatar Oct 07 '22 15:10 ZedThree

Hm, worth checking it out then (I installed FORD via Anaconda). Will keep you posted.

arjenmarkus avatar Oct 07 '22 15:10 arjenmarkus

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.

arjenmarkus avatar Oct 09 '22 11:10 arjenmarkus

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?

ZedThree avatar Oct 11 '22 10:10 ZedThree

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: @.***>

arjenmarkus avatar Oct 11 '22 12:10 arjenmarkus