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

MACRO_EXPANSION=YES seems to be broken (Origin: bugzilla #600563) #3573

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

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

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

Original attachment names and IDs:

On 2009-11-03 15:33:15 +0000, John Sturton wrote:

Setting MACRO_EXPANSION=YES seems to have no effect in v1.6.1. Works OK in v1.6.0

On 2009-11-03 20:37:08 +0000, Dimitri van Heesch wrote:

Does it still occur with the latest subversion snapshot?
If so (or if you cannot build this yourself) can you provide a self-contained example that allows me to reproduce the problem?

On 2009-11-04 07:35:46 +0000, John Sturton wrote:

(In reply to comment # 1)

Does it still occur with the latest subversion snapshot?
If so (or if you cannot build this yourself) can you provide a self-contained
example that allows me to reproduce the problem?

Sorry, I don't have the possibility to build the latest SVN version.

An example data set:

macros.h:
#define FOO(_x) int fooed##_x

macros.cpp:
#include "macros.h"
FOO(_func) (void)
/** A fooed function
*/
{
}

The config:
INPUT= macros.cpp macros.h
PERL_PATH=/usr/bin/perl
PROJECT_NAME=foo_test.obj
EXTRACT_ALL=YES
MACRO_EXPANSION=YES
EXPAND_ONLY_PREDEF=NO
HIDE_UNDOC_MEMBERS=NO
JAVADOC_AUTOBRIEF=NO
GENERATE_RTF=NO
GENERATE_MAN=NO
GENERATE_LATEX=NO
ALPHABETICAL_INDEX=YES
COLS_IN_ALPHA_INDEX=1
SOURCE_BROWSER=NO
SHOW_INCLUDE_FILES=NO

The output I get with 1.6.0 is:

int fooed_func (void)
A fooed function

The output I get with 1.6.1 is:

FOO() _func(void)
A fooed function

The 1.6.1 output is the same as that generated by 1.6.0 with MACRO_EXPANSION=NO

On 2009-11-10 04:05:33 +0000, Ben Webb wrote:

Created attachment 147351
doxygen.tar.gz

Files to reproduce the problem.

On 2009-11-10 04:09:14 +0000, Ben Webb wrote:

I see this bug is still marked NEEDINFO, so here's another data point:

I see a similar problem (see attachment 147351, doxygen.tar.gz).

For example, given foo.h:
#include "macro.h"

class Foo {
public:
int method1();
MYMACRO;
};

and macro.h:
#define MYMACRO int method2()

one might expect doxygen (if MACRO_EXPANSION and ENABLE_PREPROCESSING are
turned on) to parse two methods (method1 and method2) in the Foo class. This
was the case prior to 1.6.1; however, in 1.6.1 it does not preprocess the
MYMACRO macro (try running 'doxygen doxygen.conf' on the doxygen.conf in the attachment).

What is actually seen is something like:

Public Member Functions
int method1 ()
Public Attributes
MYMACRO

What we were expecting was:

Public Member Functions
int method1 ()
int method2 ()

Additional info:
Downgrading doxygen to 1.5.8 fixes the problem. Alternatively, manually
placing macro.h before foo.h in INPUT in doxygen.conf yields the correct
behavior. However, the latter is not a practical solution in our case since our
header dependencies are rather more complex than this simple example.

On 2009-12-24 11:36:13 +0000, Dimitri van Heesch wrote:

I can reproduce the problem with version 1.6.1, but it
appear to be fixed in the latest SVN version already.

On 2009-12-30 13:38:39 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.2. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).

On 2009-12-31 10:06:42 +0000, John Sturton wrote:

The problem as defined in Ben Webb's data set does seem to be fixed in 1.6.2. However, running 1.6.2 via our in-house scripts on our code base still gives problems :-(

======= foo.h: =========

/** \file
Foo header
*/

#ifndef FOO_H
#define FOO_H "FOO_H"

int iFoo; //!< A foo

#endif // FOO_H

======= foo.cpp: ========

/** \file
Foo implementation
*/

#include "foo.h"

=======================

Running Doxygen 1.6.2 on the given files with
INPUT=foo.cpp foo.hpp
will not document the iFoo variable.
Inverting the order to
INPUT=foo.hpp foo.cpp
will document the iFoo variable.
Modifying the foo.h file to #define FOO_H as an empty macro via
#define FOO_H
and specifying either INPUT order will document the iFoo variable.

Doxygen 1.6.1 does not have this problem
Doxygen 1.6.0 does has this problem (same as 1.6.2)
Doxygen 1.5.9 does not have this problem

On 2010-06-11 20:15:27 +0000, Dimitri van Heesch wrote:

The latest snapshot from subversion should have your last example working, except that

#define FOO_H "FOO_H"

is not detected as an include guard, so you will get a warning about it not being documented.

These alternatives are detected as guards:
#define FOO_H
or
#define FOO_H 1

On 2010-06-15 11:21:40 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.0. 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.

@doxygen doxygen closed this Jul 2, 2018

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