GNOME Bugzilla – Bug 356204
typedef replaced by actual type; doxygen doesn't recognize member function implementation
Last modified: 2006-10-19 19:21:28 UTC
Please describe the problem: In certain, very specific, situations, doxygen becomes unable to correctly match up the implementation of a member function of a class with its prototype in the class's declaration. The results in warnings of the form: /Users/ejt/doxybug/Controller.cc:6: Warning: no matching class member found for Controller & Controller::setEStopID(unsigned short estopid) Possible candidates: Controller & Controller::setEStopID(MotionManager::MC_ID estopid) Steps to reproduce: I will attach some sample code -- each file demonstrates some aspect of the bug. Actual results: Expected results: Does this happen every time? yes; tested on Mac OS X (both Intel and PowerPC) and Linux (FC3) Other information:
Created attachment 72880 [details] This is the key code which declares the typedef in question
Created attachment 72881 [details] The first example of the error Should trigger the warnings (listed below) for checkoutMotion() and convertMotion(), HOWEVER not next() or peekMotion() /Users/ejt/doxybug/MotionManager.cc:6: Warning: no matching class member found for MotionCommand * MotionManager::checkoutMotion(unsigned short mcid, bool block) Possible candidates: MotionCommand * MotionManager::checkoutMotion(MC_ID mcid, bool block=true) /Users/ejt/doxybug/MotionManager.cc:11: Warning: no matching class member found for MotionCommand * MotionManager::convertMotion(unsigned short mc) Possible candidates: void MotionManager::convertMotion(MotionManager::MC_ID mcid)
Created attachment 72882 [details] Appears to be necessary to trigger bug The odd thing is that this does not reference, nor is referenced by, the other code. Something about this completely independent member variable declaration gets the ball rolling.
Created attachment 72883 [details] Setup for another example of the error Just to illustrate the problem occurs in references throughout the project, not just in the original class
Created attachment 72884 [details] Another example of the error The file should generate the error shown below: /Users/ejt/doxybug/Controller.cc:6: Warning: no matching class member found for Controller & Controller::setEStopID(unsigned short estopid) Possible candidates: Controller & Controller::setEStopID(MotionManager::MC_ID estopid)
Created attachment 72885 [details] This file can cause the error to go away In a very strange twist, by *un*commenting the member variable in this class, which is for all I can tell identical to SpeakerServer, will cause the error to go away in all of the other classes. Even stranger is that when SpeakerServer is commented out and this remains, it is unable to trigger the bug the way SpeakerServer does. The difference between these two files may be a crucial clue, but I can't find it.
Created attachment 72886 [details] doxygen settings file I haven't played with the doxygen settings much, these were what I was using for testing. Just a straightforward 'doxygen doxygencfg' with the other files in the same directory to trigger the problem: ~/doxybug$ ls Controller.cc MotionManager.cc SpeakerServer.h doxygencfg Controller.h MotionManager.h Uninvolved.h ~/doxybug$ doxygen doxygencfg /Users/ejt/doxybug/Controller.cc:6: Warning: no matching class member found for Controller & Controller::setEStopID(unsigned short estopid) Possible candidates: Controller & Controller::setEStopID(MotionManager::MC_ID estopid) /Users/ejt/doxybug/MotionManager.cc:6: Warning: no matching class member found for MotionCommand * MotionManager::checkoutMotion(unsigned short mcid, bool block) Possible candidates: MotionCommand * MotionManager::checkoutMotion(MC_ID mcid, bool block=true) /Users/ejt/doxybug/MotionManager.cc:11: Warning: no matching class member found for MotionCommand * MotionManager::convertMotion(unsigned short mc) Possible candidates: void MotionManager::convertMotion(MotionManager::MC_ID mcid)
I'm building a copy of doxygen from CVS, will post a comment if there's any difference. This error may be related to bug 333084: http://bugzilla.gnome.org/show_bug.cgi?id=333084
Can you please attach your test case(s) as a self-contained archive? So a zip/tarred dir with source code + config file, so I can: 1) extract the archive 2) cd to the dir 3) run doxygen 4) see the error message. This prevents a lot of hassle and potential confusion from my side.
Created attachment 72899 [details] zip archive of attachments
Thanks. I can reproduce the problem now. The root cause seems to be HIDE_UNDOC_RELATIONS = NO This introduces "unsigned short" as a type, causing all types after its introduction to resolve differently than the ones before (the result of type resolution is cached). Doxygen should ignore such types for type resolution, so I'll add this.
This bug was marked "assigned" by me some time ago, which means it should be fixed in version 1.5.0 and is hereby marked as such. I would kindly request you to check if this version indeed fixes the problem and reopen the bug report should you still see the same problem.