GNOME Bugzilla – Bug 531637
Hang on templated class typedefs
Last modified: 2018-07-30 10:26:45 UTC
Steps to reproduce: Source Code... /**************************************/ #include <iterator> template <class T> class ListItem {}; template <class BASE, class T> class DervivedList : public BASE { template <class BB, class TT> class bidirectional_iterator : public std::iterator< std::bidirectional_iterator_tag, ListItem<TT> > {}; typedef bidirectional_iterator<BASE,T> iterator; }; int main() { return 0; } /**********************************************/ At the command line... $doxygen Stack trace: Other information: Hangs at "Computing class inheritance relations..."
I just noticed something. This appears to be a recursive name lookup issue. When I changed the typedef from iterator to foobar all was well. So shouldn't doxygen take the namespace into account in this case? #include <iterator> template <class T> class ListItem {}; template <class BASE, class T> class DervivedList : public BASE { template <class BB, class TT> class bidirectional_iterator : public std::iterator< std::bidirectional_iterator_tag, ListItem<TT> > {}; // change this from iterator to foobar and all is well!! typedef bidirectional_iterator<BASE,T> foobar; }; int main() { return 0; }
Sorry about this, but once last clarification. The core issue occurs when the derived class matches the typedef. In this case iterator is the typedef and iterator is the base class for the nested class... /// This hangs... template <class BB, class TT> class bidirectional_iterator : public iterator<...> {}; typedef bidirectional_iterator<BASE,T> iterator; /// This works... template <class BB, class TT> class bidirectional_iterator : public std::iterator<...> {}; typedef bidirectional_iterator<BASE,T> iterator; So my first comment on the bug was incorrect, but I believe this clarification should narrow down the issue.
To avoid any confusion it is best to attach a self-contained example (source + config file in a zip) to this bug report so that I can more easily reproduce the problem. Can you still do this?
Created attachment 110507 [details] Source+config
Comment on attachment 110507 [details] Source+config The attached code and config will demo the problem completely. This should resolve all confusions
I'd like to add this doxygen 1.7.1 is also hanging on code similar to what Andrew posted. The code is part of KDE and is extensive. But I can point you to it if you want to take a look.
Seems the issue in the attached example has been fixed since version 1.6.2, so if you have another example that still hangs doxygen I'm very interested.
Created attachment 169668 [details] Akonadi source file that hangs Doxygen
Hi Dimitri. I'm using doxygen 1.7.1. The code in question is the Akonadi library that is part of the KDE project and is much too large to attach to this bug report. It is available at http://websvn.kde.org/trunk/KDE/kdepimlibs/akonadi or from svn using svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepimlibs/akonadi The specific file showing the hang is itempayloadinternals_p.h (attached). It has many templates. You'll notice that I put a big @cond PRIVATE block around the code in that file to get around the hang problem, so to test it you'll want to remove that Doxygen conditional.
Reopening as an example has been provided.
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to https://github.com/doxygen/doxygen/issues All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github. Hence I am closing this GNOME Bugzilla ticket. Please use the corresponding ticket in Github instead. Thanks a lot!