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 333084 - resolution failure involving using declaration of typedef to non-class type
resolution failure involving using declaration of typedef to non-class type
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.4.x
Other All
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2006-03-02 05:26 UTC by Stephen C. Pope
Modified: 2013-05-05 13:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch to fix bug (376 bytes, patch)
2006-03-02 05:33 UTC, Stephen C. Pope
none Details | Review

Description Stephen C. Pope 2006-03-02 05:26:38 UTC
Please describe the problem:
When doxygen encounters a using declaration for a type which is a typedef to a
non-class type (i.e. builtin type such as in), getResolvedClass() returns
incorrect results which causes findUsingDeclarations() to incorrectly generate a
"bogus" ClassDef for the type rather than using the MemberDef representing the
typedef. As a result, failures to resolve a method definition with its
declaration can result

Steps to reproduce:
1. Run doxygen against the following source:

namespace a {
   /// typedef doc
   typedef uint32_t A;
}

namespace b {
   /// class doc.
   class B {
      public:
      /// fun doc.
      void fun(a::A arg);
   };
}

using a::A;

namespace b {
   /** detailed doc. */
   void B::fun(A arg) {}
}



Actual results:
The following error message is generated:

/home/scp/bug.cpp:19: Warning: no matching class member found for
  void b::B::fun(A arg)
Possible candidates:
  void b::B::fun(a::A arg)


Expected results:
No error message

Does this happen every time?
yes

Other information:
The problem occurs when the type in the using declaration is a typedef to a
non-class type, because getResolvedClassRec() is failing to return the MemberDef
for a typedef which does not resolve to a class type. As a result,
findUsingDeclarations() ends up creating and installing a "bogus" <using>
ClassDef to represent the imported type. If the method definition then uses this
imported type, it will not resolve with the method declaration (which is assumed
to be using the same type but not via a using declaration).

It should be noted that this same input will generate the same error for other
reasons unless the (currently proposed) patch for PR 333053 has already been
applied, in which case the problem discussed here is unmasked.

I include a proposed patch in the following attachment.
Comment 1 Stephen C. Pope 2006-03-02 05:33:38 UTC
Created attachment 60462 [details] [review]
proposed patch to fix bug

Here is a patch against the current CVS HEAD for util.cpp to fix the problem. Basically, when a typedef to a non-class type is found at the minimum distance, getResolvedClassRec() should return the MemberDef via the pTypeDef argument even when returning nil for the ClassDef.
Comment 2 albert 2013-05-05 12:52:59 UTC
With version 1.4.6 I get the same error message, when running version 1.8.3.1
the messages don't appear.

I think that the problem has been solved in the mean time.
Comment 3 Dimitri van Heesch 2013-05-05 13:47:13 UTC
Setting to fixed as suggested. Please reopen this bug report if you still see this issue with the latest version of doxygen. Add a self-contained example (source+config file in a zip or tar) if possible.