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 670235 - #define in conditionally compiled block not documented
#define in conditionally compiled block not documented
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: build
1.7.6.1
Other Windows
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
: 670237 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-02-16 17:33 UTC by Martin Sauerhoff
Modified: 2012-05-19 12:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Doxygen input files to reproduce bug (19.71 KB, application/x-7z-compressed)
2012-02-16 17:33 UTC, Martin Sauerhoff
Details

Description Martin Sauerhoff 2012-02-16 17:33:20 UTC
Created attachment 207796 [details]
Doxygen input files to reproduce bug

The problem arises with constructs of the following type:

//! \def BLA
//! \brief Comment for BLA.

#ifndef BLA
#define BLA 0
#endif

Assume that this is contained in a file defs.h and another file otherfile.h
including this defs.h is evaluated by doxygen before defs.h itself is evaluated.
Then the define BLA is not documented. (See attached example.)

Reason: When defs.h is evaluated for the first time by doxygen as an #include 
of otherfile.h, its defines are stored in a file -> definitions map. When 
defs.h is evaluated again, the stored defines are copied to its initial 
context. Hence, in the described situation, BLA is erroneously already 
defined when the #define is parsed, and the #define is stripped away
by the preprocessor.

A solution may be to remove the instruction adding the the stored defines
for a parsed file itself, 

  DefineManager::instance().addFileToContext(g_yyFileName);

in function preprocessFile (line 2779 of src/pre.l). I do not know what the
side-effects of this are, though, and why the instruction is there in the
first place.
Comment 1 Dimitri van Heesch 2012-02-16 19:01:37 UTC
*** Bug 670237 has been marked as a duplicate of this bug. ***
Comment 2 Dimitri van Heesch 2012-03-10 13:46:10 UTC
Hi Martin,

This is an include guard detection problem, like for bug #670237.
I'll make doxygen parse the "#pragma once" and when found use that to stop looking for include guards.

If you want to try, here is the patch I have in mind:

--- ../../doxygen-svn/src/pre.l	2012-02-25 15:21:29.000000000 +0100
+++ pre.l	2012-03-10 14:34:45.000000000 +0100
@@ -2073,6 +2073,9 @@
   					  BEGIN(Start);
 					  g_yyLineNr++;
   					}
+<Command>"pragma"{B}+"once"             {
+                                          g_expectGuard = FALSE;
+                                        }
 <Command>{ID}				{ // unknown directive
 					  BEGIN(IgnoreLine);
 					}
Comment 3 Martin Sauerhoff 2012-03-15 09:24:38 UTC
Hi Dimitri,

Thanks for the patch. I think this provides an acceptable workaround 
for bug 670235 (it is not a 100 % solution since it only works if you 
actually use "#pragma once", but I think this is okay). It will probably 
do nothing to solve bug 670237, though.
Comment 4 Dimitri van Heesch 2012-05-19 12:26:55 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.1. 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.