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?

(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

Created attachment 147351 [details]
doxygen.tar.gz

Files to reproduce the problem.

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


I see a similar problem (see attachment 147351 [details], 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.

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

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

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

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

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.