"protected" structs in Objective-C

There seems to be a bit of a nasty bug where a struct as an instance  
member of an Objective-C interface will make doxygen crap.

If you're on OS X, make sure EXTRACT_ALL is on, and set INPUT to this  
single header file (the AppKit headers make a good example for  
Objective-C header files):

	/System/Library/Frameworks/AppKit.framework/Headers/NSBitmapImageRep.h

Now run dox. Review the output -- there's nothing documented.

The problem is this block in that header file:

@interface NSBitmapImageRep : NSImageRep {
     /*All instance variables are private*/
     struct __bitmapRepFlags {
        unsigned int bitsPerPixel:8;
         unsigned int isPlanar:1;
         unsigned int explicitPlanes:1;
         unsigned int isUnpacked:1;
         unsigned int dataLoaded:1;
         unsigned int numColors:4;       /* Cache */
          unsigned int memory:2;
         unsigned int compressionFactor:14;
         unsigned int imageNumber:8;
         unsigned int bitmapFormat:3;
         unsigned int reserved:1;
         unsigned int compression:20;
     } _moreRepFlags;
     unsigned int _bytesPerRow;
     unsigned char *_data;
     NSData *_tiffData;
     id _properties;
}

The struct called __bitmapRepFlags is the problem. Commenting that  
out like so:

@interface NSBitmapImageRep : NSImageRep {
     /*All instance variables are private*/
    /*
    struct __bitmapRepFlags {
        unsigned int bitsPerPixel:8;
         unsigned int isPlanar:1;
         unsigned int explicitPlanes:1;
         unsigned int isUnpacked:1;
         unsigned int dataLoaded:1;
         unsigned int numColors:4;       /* Cache */
          unsigned int memory:2;
         unsigned int compressionFactor:14;
         unsigned int imageNumber:8;
         unsigned int bitmapFormat:3;
         unsigned int reserved:1;
         unsigned int compression:20;
     } _moreRepFlags;
     */
     unsigned int _bytesPerRow;
     unsigned char *_data;
     NSData *_tiffData;
     id _properties;
}

...and then running dox again results in complete documentation for  
that header file. It seems whenever dox finds a struct as a protected  
member, something happens such that it doesn't add any of the symbols  
to the group to document.

Has anyone else seen this issue? I would be happy to write a patch  
for this, but I'd appreciate some pointers as to where to search for  
the problem. I've been able to determine that once parseFiles() hits  
the struct, neither it or any of the following symbols get placed  
onto the "root" variable that eventually gets munged by buildGroupList 
(). But finding the problem within parseFiles() and the associated  
lex, I don't know where to start.

Thanks for your help.

Ryan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642