GNOME Bugzilla – Bug 786409
parsing error in Fortran file with preprocessing
Last modified: 2017-12-25 18:43:38 UTC
Created attachment 357782 [details] 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.
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 00002 00003 #define _WWf_(f) 00004 00005 CONTAINS 00006 00007 subroutine s 00008 00009 00010 00011 00012 00013 00014 --------- Macros accessible in this file: --------- _WWf_ ---------
Huh, that's strange. GCC's preprocessor produces the expected result, of course: $ cpp m.F90 # 1 "m.F90" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "m.F90" MODULE m CONTAINS subroutine s write(*,'(a,e10.5)') 'XXX', 4. end subroutine end MODULE Does doxygen have its own preprocessor?
Yes, doxygen has its own preprocessor.
(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.
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.
I just pushed a proposed patch (pull request 589) to github.
(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: MODULE m2 #define _WRITE_IT_(evalOpt) write(*,*) evalOpt CONTAINS subroutine s() _WRITE_IT_( 'a' // 'b' ) end subroutine end MODULE doxygen output: Preprocessing /home/jweil/fort/doxygen_bugs/786409/m2.F90... Preprocessor output (size: 87 bytes): --------- 00001 MODULE m2 00002 #define _WRITE_IT_(evalOpt) 00003 CONTAINS 00004 subroutine s() 00005 // 'b' ) 00006 00007 00008 --------- Macros accessible in this file: --------- _WRITE_IT_ --------- 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).
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.
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.
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!
both updates have been integrated into the main version on github
(In reply to albert from comment #11) > both updates have been integrated into the main version on github That's great news. Thank you!
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).