On 8/28/2014 4:30 PM, Jeffrey Melville wrote: > Dimitri, > > On 8/28/2014 2:03 PM, Dimitri van Heesch wrote: >> Hi Jeffrey, >> >> On 27 Aug 2014, at 17:59 , Jeffrey Melville <jmelvi...@mitre.org> wrote: >> >>> All, >>> >>> I'm working on two closely related source trees that generate Doxygen >>> separately. To cross-link the Doxygen HTML, we just started using >>> GENERATE_TAGFILE and TAGFILES for ProjectA and Project B respectively. >>> >>> I noticed that some functions are missing from the tag file in 1.8.6, >>> 1.8.8, and the current git head. The tag file is complete when I >>> generate it with 1.8.2. The was a similar thread >>> (http://doxygen.10944.n7.nabble.com/Tag-files-and-linking-to-variables-td5788.html) >>> that referenced this bug: >>> (https://bugzilla.gnome.org/show_bug.cgi?id=694376). The bug was >>> supposed to be fixed in 1.8.4 but I am still seeing my issue. >>> >>> It seems to involve hierarchies similar to the one below. In the actual >>> codebase, all members are documented but I ommitted the documentation >>> here for brevity. >>> >>> The tag file only includes private members of class A (i.e. foo is not >>> listed). In one case, >>> the tag file for a B-style class even includes the function ~A(). >>> >>> This is problematic because the ProjectB documentation for class C does >>> not properly link to the overridden function in ProjectA. >>> >>> If I generate the tag file for ProjectA using Doxygen 1.8.2, then build >>> the Doxygen for ProjectB with Doxygen 1.8.6 using that tag file, >>> everything is fine. We have some compatibility issues with the rest of >>> the Doxyfile with 1.8.2. >>> >>> Unfortunately, I haven't been able to replicate the problem with a >>> simple test case like this one. It only occurs with the full codebase, >>> which I am unable to provide. >>> >>> Is this enough for anyone to have an idea? I'm not opposed to hacking on >>> the Doxygen source code to find a patch but I could use a tip on where >>> to start looking. >> >> I'm afraid it is not enough to directly pinpoint the problem. >> Some questions: >> - does the issue occur with just one tag file, and one project using it, or >> is there >> a chain of tag files, where also projectA imports tag files? > > No, ProjectA does not import any tag files. It does declare > BUILTIN_STL_SUPPORT. ProjectB is the only consumer of ProjectA's tag > file. It only imports the single tag file. > >> - is a symbol with the same name as the one that is not correctly appearing >> in projectA's tag file (i.e. foo), also in some other tag file? > > No, since project A does not import any other tag flies. > I don't know if this matters, but another source file forward declares > one of the affected classes. > >> >> If you want to see places in the code where information is written to the >> tag file, >> look for "Doxygen::tagFile" in the source code. For member information look >> in >> src/memberdef.cpp > > Ok. I'll poke around. Have there been any significant changes since > 1.8.2 in the way tag files are generated? > >> >> Regards, >> Dimitri >> > > Thanks, > Jeff > > P.S. Sorry for the double send, I forgot to include the list. > >>> >>> Cheers, >>> Jeff >>> >>> >>> // Class A and B are in ProjectA >>> class A >>> { >>> public: >>> virtual ~A() {} >>> virtual void foo() {} >>> protected: >>> A() {} >>> private: >>> int a_private; >>> }; >>> >>> class B : public A >>> { >>> public: >>> virtual ~B() {} >>> virtual void bar() = 0; >>> protected: >>> B() {} >>> private: >>> int b_private; >>> }; >>> >>> // Class C is in ProjectB >>> class C : public B >>> { >>> public: >>> void foo() { /* Do something */ } >>> void bar() { /* Do something */ } >>> }; >>> >>> ------------------------------------------------------------------------------ >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> http://tv.slashdot.org/ >>> _______________________________________________ >>> Doxygen-users mailing list >>> Doxygen-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/doxygen-users >> > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Doxygen-users mailing list > Doxygen-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/doxygen-users >
Thanks for the tip, I made some progress on tracking down this issue. It is very closely related to: https://bugzilla.gnome.org/show_bug.cgi?id=694376. The problem is that each member can have _writeTagData called more than once. The fix for the previous bug addressed cases where _writeTagData is called for different "compound types." It's still possible for _writeTagData to be called multiple types for each class in an inheritance hierarchy when functions are inherited but not overridden. Things get really weird when the derived class gets processed before the base class (as is the case in my codebase). The call to writeInheritedMemberDeclarations marks the tagDataWritten flag for functions inherited from the base class, preventing them from being emitted when the base class is processed. Below is a patch that fixed the problem on my codebase. I'm not sure if it breaks other cases where you actually want to suppress the tag data being generated multiple times. I can submit a Github pull request if you'd prefer. Cheers, Jeff From b874223b33d4939c53b42df75ce62bcc4acea318 Mon Sep 17 00:00:00 2001 From: Jeffrey Melville <jmelvi...@mitre.org> Date: Mon, 8 Sep 2014 13:16:29 -0400 Subject: [PATCH] Fix for missing inherited class members in tag files. Signed-off-by: Jeffrey Melville <jmelvi...@mitre.org> --- src/memberdef.cpp | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/memberdef.cpp b/src/memberdef.cpp index a25528a..8626e5e 100644 --- a/src/memberdef.cpp +++ b/src/memberdef.cpp @@ -3550,7 +3550,11 @@ Specifier MemberDef::virtualness(int count) const void MemberDef::_writeTagData(const DefType compoundType) { unsigned typeMask = 1 << compoundType; - if ((m_impl->tagDataWritten) & typeMask) return; // member already written for this type + + // Return if member already written for this compoundType, except if + // compoundType is a class. This function can be run multiple times for + // classes in an inheritance hierarchy. + if (compoundType != TypeClass && (m_impl->tagDataWritten) & typeMask) return; if (m_impl->mtype==MemberType_EnumValue && m_impl->enumScope && m_impl->enumScope->isStrong()) return; // enum value is part of enum static bool generateTagFile = !Config_getString("GENERATE_TAGFILE").isEmpty(); -- 1.9.1 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Doxygen-users mailing list Doxygen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/doxygen-users
