After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 570238 - "No matching class member found" warning is incorrect
"No matching class member found" warning is incorrect
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.5.8
Other All
: Normal minor
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2009-02-02 16:47 UTC by Nick
Modified: 2009-08-20 10:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case with source code and log output (3.36 KB, application/octet-stream)
2009-02-02 16:50 UTC, Nick
Details

Description Nick 2009-02-02 16:47:32 UTC
Please describe the problem:
This warning should not be issued in this context. I can build code with no warnings, and am "using Rc::Exec::HelperThread;" right above the implementation.

Error:
C:/users/npcostes/TGP-branch/B52TGP/TgpLib/Rc/Tgp/HelperThreads/CaptureThread/Requests/SetCaptureThreadChannel.cpp:26: Warning: no matching class member found for
  SetCaptureThreadChannel::SetCaptureThreadChannel(Rc::Tgp::HelperThreads::CaptureThreadChannel channel, HelperThread *helperThread)
Possible candidates:
  Rc::Tgp::HelperThreads::SetCaptureThreadChannel::SetCaptureThreadChannel(const Rc::Tgp::HelperThreads::CaptureThreadChannel channel=Rc::Tgp::HelperThreads::CaptureThreadChannel::e_flir, Rc::Exec::HelperThread *helperThread=0)
  Rc::Tgp::HelperThreads::SetCaptureThreadChannel::SetCaptureThreadChannel(const SetCaptureThreadChannel &request)


Declaration:
            SetCaptureThreadChannel (const Rc::Tgp::HelperThreads::CaptureThreadChannel channel = Rc::Tgp::HelperThreads::CaptureThreadChannel::e_flir, 
               Rc::Exec::HelperThread* helperThread = 0);


Implementation:
using Rc::Tgp::HelperThreads::SetCaptureThreadChannel;

using Rc::Tgp::HelperThreads::CaptureThreadChannel;
using Rc::Exec::HelperThread;

SetCaptureThreadChannel::SetCaptureThreadChannel(const CaptureThreadChannel channel, 
                                                 HelperThread* helperThread)
: HelperThreadRequest(HelperThreadRequest::Type::e_setCaptureThreadChannel, helperThread),
m_channel (channel)
{
   setHelperThreadName ("CaptureThread");
}


Steps to reproduce:
1. Run doxygen on the above code.
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
yes

Other information:
If I change the implementation to be

const CaptureThreadChannel channel,                                Rc::Exec::HelperThread* helperThread)

Then doxygen emits no warning. Note that since I am "using Rc::Exec::HelperThread;" I think I should not have to fully qualify it in the implementation (esp. since it compiles w/no warnings).
Thanks!
Comment 1 Nick 2009-02-02 16:50:59 UTC
Created attachment 127771 [details]
test case with source code and log output
Comment 2 Nick 2009-02-02 16:54:32 UTC
Also, adding a "using namespace Rc::Exec;" instead of "using Rc::Exec::HelperThread;"  doesn't help. Only fully qualifying the parameter type as Rc::Exec::HelperThread* makes the Doxygen warning go away.

PS: Thank you so much for writing and maintaining Doxygen, it is a wonderful tool.
Comment 3 Wolfgang Bangerth 2009-02-10 19:33:39 UTC
Here's a small and self contained testcase:
-----------------------
template<typename T> struct B {
    struct I { I(); };
};

template<typename T> struct D : B<T> {};

template<typename T>
B<T>::I::I () {}
-----------------------
For this one I get the following:

/precondition_block.h:8: Warning: no matching class member found for
  template < T >
  B< T >::I::I()

Best
 Wolfgang
Comment 4 Dimitri van Heesch 2009-08-12 12:13:18 UTC
Wolfgang: thanks for the test case.
The problem should be fixed in the next release.
Comment 5 Dimitri van Heesch 2009-08-20 10:13:02 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.0. 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).