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

[doxygen]

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:

• doxygen_bug.tar.gz (ID 357782)

On 2017-08-17 09:23:09 +0000, janus@gcc.gnu.org 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
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

On 2017-08-17 14:30:51 +0000, janus@gcc.gnu.org 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"

MODULE m

CONTAINS

subroutine s

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

end subroutine

end MODULE

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, janus@gcc.gnu.org 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, janus@gcc.gnu.org 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:

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).

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, janus@gcc.gnu.org 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, janus@gcc.gnu.org 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).