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

Fortran: quotation after define causes error (Origin: bugzilla #623299) #3834

Closed
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

status VERIFIED severity normal in component general for ---
Reported in version 1.8.7 on platform Other
Assigned to: Dimitri van Heesch

On 2010-07-01 15:25:13 +0000, Andy May wrote:

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

On 2010-07-03 08:46:36 +0000, albert wrote:

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.

On 2010-10-12 08:28:33 +0000, Andy May wrote:

The problem remains in 1.7.2

On 2010-12-22 19:46:00 +0000, Daniel Franke wrote:

*** This bug has been marked as a duplicate of bug 625601 ***

On 2011-03-31 12:26:18 +0000, Andy May wrote:

I modify the version for this bug simply because I'm unable to modify version for bug625601

On 2014-04-21 10:39:39 +0000, Andy May wrote:

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

On 2014-04-21 18:12:45 +0000, albert wrote:

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.

On 2014-04-22 07:30:26 +0000, Andy May wrote:

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.

On 2014-08-21 17:15:24 +0000, Dimitri van Heesch wrote:

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

On 2014-08-24 18:21:43 +0000, Andy May wrote:

I agree, it works now. Thanks very much!

@doxygen doxygen closed this Jul 19, 2018

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