GNOME Bugzilla – Bug 535379
Doxygen fails to parse IDL files as used in Mozilla correctly
Last modified: 2008-09-28 19:16:08 UTC
Please describe the problem: When running doxygen on the Mozilla source code, I noticed that it seems to omit some interfaces which turn out to be heavily used, for example nsIURI and nsISupportsArray. Although Mozilla uses several macros internally, the IDL files omit (for the most part) these macros. My cursory examination of the output seems to indicate that the problem is that information is being misparsed. It seems that the %{C++ ... %} block is what is messing up the documentation. Steps to reproduce: 1. Checkout the mozilla sources (only tested with CVS sources, not tarballs or hg source) 2. Configure the build to produce a makefile 3. Run |make export documentation|. (May help to narrow the documented classes to nsISupports*.idl instead of *.idl, *.h, *.cpp) 4. Check the documentation for the file nsISupportsArray.idl Actual results: The documented entities are: native nsISupportsArrayEnumFunc(nsISupportsArrayEnumFunc) uuid(791eafa0-b9e6-11d1-8031-006008159b5a) Expected results: The documented entities should be (at least): native nsISupportsArrayEnumFunc(nsISupportsArrayEnumFunc) interface nsISupportsArray + functions therein Probably the other functions as well Does this happen every time? Yes Other information: I do not know if the %{C++ ... %} syntax is merely a Mozilla XPIDL property or if it applies to other types of IDL files. I also do not require that the functions in such a block be documented, so treating it as a comment is fine at least by me.
Created attachment 111826 [details] [review] Patch to fix the problem This patch is a simple fix that generates the correct documentation for the IDL files in question.
Actually, that last patch is wrong; whitespace is allowed between the '%{' and the 'C++' tokens; I'll update when I get some more time.
Created attachment 115063 [details] [review] Better fix for the problem So I've finally gotten around to fixing this issue correctly. My biggest blocker was not realizing that the quotation marks actually made a difference (stupid me, I know). This is also a bit more generic, not hardcoding in a string any more.
I think this is indeed XPCOM specific, but I think it is safe to include your last patch anyway.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.5.7. 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).