After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 623299 - Fortran: quotation after define causes error
Fortran: quotation after define causes error
Status: VERIFIED FIXED
Product: doxygen
Classification: Other
Component: general
1.8.7
Other Linux
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on: 625601
Blocks:
 
 
Reported: 2010-07-01 15:25 UTC by Andy May
Modified: 2014-08-24 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andy May 2010-07-01 15:25:13 UTC
The following test.f file:

#define TEST_DEFINE
c some non-doxygen comment, written '93

or indeed, with double quotes:

#define TEST_DEFINE
c some non-doxygen comment, written "93

causes an error:

Parsing file /home/andy/bug/test.f...                       
********************************************************************
Error in file /home/andy/bug/test.f line: 4, state: 20              
********************************************************************

The error is not seen if the #define is removed. The error is also not seen if the comment character is changed from 'c' to '!'.

This is seen with doxygen 1.7.1 using binary version from the website:

doxygen-1.7.1.linux.bin.tar.gz
Comment 1 albert 2010-07-03 08:46:36 UTC
As far as I can see this has to do with the determination of the type of format of the Fortran code (Fee formatted against Fixed). It looks like that it is determined that it is free formatted code and thus the 'c' is not a comment character.
When placing a the first line a comment line starting with a 'c' or eg. '      subroutine' etc. it is recognised as fixed format code and no error message is given.
Comment 2 Andy May 2010-10-12 08:28:33 UTC
The problem remains in 1.7.2
Comment 3 Daniel Franke 2010-12-22 19:46:00 UTC

*** This bug has been marked as a duplicate of bug 625601 ***
Comment 4 Andy May 2011-03-31 12:26:18 UTC
I modify the version for this bug simply because I'm unable to modify version for bug625601
Comment 5 Andy May 2014-04-21 10:39:39 UTC
The bug which this bug has been marked a duplicate of has been marked as resolved, but I still see this problem:

test> doxygen -v
1.8.7
test> doxygen -g
...
test> doxygen
...
********************************************************************
Error in file /home/andy/test/test.F line: 5, state: 21
********************************************************************
...
test> cat test.F
#define TEST_DEFINE
c some non-doxygen comment, written '93
      subroutine test
      end
Comment 6 albert 2014-04-21 18:12:45 UTC
It not possible to determine with 100% certainty whether a Fortran source file is free or fixed formatted code. The referenced bug_625601 solves this problem by defining 2 "new" languages for the EXTENSION_MAPPING: FortranFixed and FortranFree which sets the apropriate source form. When no explicite language is set or Fortran is set doxygen tries to determine the the source form (very limited). See also the documentation.

I've just pushed a solution, where lines starting with a # (with zero or more spaces in front of it) are seen as comment lines for the determination whether or not the file is free or fixed formatted Fortran code. Pull request 159.
Comment 7 Andy May 2014-04-22 07:30:26 UTC
I agree it's a difficult problem, although the proposed solution:

https://bugzilla.gnome.org/show_bug.cgi?id=625601#c7

looks a good one to me. It seems a widely adopted convention such that I don't know of any compiler (latest version) that doesn't conform to this, certainly the .f vs .f90 for fixed vs free and upper case to indicate additionally preprocessing.
Comment 8 Dimitri van Heesch 2014-08-21 17:15:24 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.8. 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 (preferrably in the form of a self-contained example).
Comment 9 Andy May 2014-08-24 18:21:43 UTC
I agree, it works now. Thanks very much!