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

parsing error in Fortran file with preprocessing (Origin: bugzilla #786409) #6238

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

status RESOLVED severity normal in component general for ---
Reported in version 1.8.14-GIT on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2017-08-17 09:23:09 +0000, wrote:

Created attachment 357782
tarball with Fortran module and Doxyfile

Please consider the simple Fortran module plus Doxyfile in the attachment.

Running doxygen on it (current master branch from github) shows output like:

Parsing files
Preprocessing /home/janus/fort/doxygen_bugs/m.F90...
Parsing file /home/janus/fort/doxygen_bugs/m.F90...

Error in file /home/janus/fort/doxygen_bugs/m.F90 line: 14, state: 4

AFAICS this is valid Fortran 90 code. Preprocessing with macro expansion is required to trigger the bug.

On 2017-08-17 14:19:33 +0000, albert wrote:

Looks like the preprocessor does not do the right translation. doxygen -d preprocessor gives:
Preprocessing D:/speeltuin/bug_786409/m.F90...
Preprocessor output (size: 72 bytes):

00001 MODULE m
00003 #define WWf(f)
00007 subroutine s

Macros accessible in this file:


On 2017-08-17 14:30:51 +0000, wrote:

Huh, that's strange. GCC's preprocessor produces the expected result, of course:

$ cpp m.F90

1 "m.F90"

1 ""

1 ""

1 "/usr/include/stdc-predef.h" 1 3 4

1 "" 2

1 "m.F90"



subroutine s

     write(*,'(a,e10.5)') 'XXX', 4.

end subroutine


Does doxygen have its own preprocessor?

On 2017-08-17 14:33:11 +0000, albert wrote:

Yes, doxygen has its own preprocessor.

On 2017-08-17 14:49:31 +0000, wrote:

(In reply to albert from comment # 3)

Yes, doxygen has its own preprocessor.

... with its own bugs, apparently :P

It's funny that it not only messes up the line where the macro occurs, but seems to swallow everything after that.

Note that my example is the most reduced test case I could find. Seems it requires a sufficient amount of dots, commas and brackets to fool the preprocessor.

On 2017-08-17 16:12:06 +0000, albert wrote:

The problem here is that the string (for the format / replacement string) had as string delimiters a single quote. In Fortran a string can be delimited by single or double quotes.

On 2017-08-17 16:12:40 +0000, albert wrote:

I just pushed a proposed patch (pull request 589) to github.

On 2017-08-17 19:27:28 +0000, wrote:

(In reply to albert from comment # 6)

I just pushed a proposed patch (pull request 589) to github.

Thanks a lot for the quick fix. As commented on github, it works great.

However, I'm seeing yet another problem, which might be of a similar kind.

Test case:

#define WRITE_IT(evalOpt) write(,) evalOpt
subroutine s()
WRITE_IT( 'a' // 'b' )
end subroutine

doxygen output:

Preprocessing /home/jweil/fort/doxygen_bugs/786409/m2.F90...
Preprocessor output (size: 87 bytes):

00001 MODULE m2
00002 #define WRITE_IT(evalOpt)
00004 subroutine s()
00005 // 'b' )

Macros accessible in this file:


Parsing file /home/jweil/fort/doxygen_bugs/786409/m2.F90...

Error in file /home/jweil/fort/doxygen_bugs/786409/m2.F90 line: 8, state: 4

Apparently the doxygen preprocessor has trouble dealing with '//', which is the string concatenation operator in Fortran. I'm guessing this is because // indicates a comment in C++?

Note that "cpp -traditional-cpp m2.F90" produces the expected result, while "cpp m2.F90" complains:

m2.F90:7:0: error: unterminated argument list invoking macro "WRITE_IT"

gfortran accepts the test case as a valid Fortran file (it invokes cpp in traditional mode).

On 2017-08-18 07:50:26 +0000, albert wrote:

Indeed looks like a similar problem. The // looks indeed like a comment and this might cause some problems (problem might here be like in cpp that the preprocessor is used for another cause than originally planned).
I'll see if I can find some time to fix this as well.

On 2017-08-18 09:56:27 +0000, albert wrote:

I just pushed a proposed patch (pull request 590) to github.

As the problem, as analyzed already by Janus, has to do with comment versus Fortran string concatenation and is independent from the original single quote it has been submitted as a separate pull request.

On 2017-08-18 10:14:51 +0000, wrote:

Also the second fix works flawlessly and, together with the first, fixes all the preprocessing problems I have observed on my Fortran code. Thank you so much!

On 2017-09-02 16:19:09 +0000, albert wrote:

both updates have been integrated into the main version on github

On 2017-09-02 16:48:20 +0000, wrote:

(In reply to albert from comment # 11)

both updates have been integrated into the main version on github

That's great news. Thank you!

On 2017-12-25 18:43:38 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.14. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment