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 557026 - DocSet Tokens.xml file mislabels most symbols
DocSet Tokens.xml file mislabels most symbols
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.5.7.1
Other Mac OS
: Normal major
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2008-10-20 04:36 UTC by Peter
Modified: 2009-08-20 10:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample header and Tokens.xml file show incorrect markup (1.14 KB, application/x-compressed-tar)
2008-10-20 04:39 UTC, Peter
  Details
Proposed patch that fixes all the issues (3.21 KB, patch)
2009-07-29 17:50 UTC, Peter
none Details | Review

Description Peter 2008-10-20 04:36:14 UTC
When generating a docset, most Objective-C API symbols are marked up incorrectly.  As a result, the symbols do not show up in Xcode's Research Assistant.

I've created a sample header for a bunch of different ObjC symbols and listed their proper apple_ref (the basis of the TokenIdentifier structure) as \brief documentation.  I will attach the header and resulting Tokens.xml files to this bug (if possible).  You can compare each token's TokenIdentifier with its Abstract element to see each mismatch.

Two significant things to highlight though...

1. "@interface" defines an ObjC class (or in some cases category on a class) and should be listed as type='cl', but doxygen marks it up as type='intf'.  "@protocol" defines an ObjC protocol and should be listed as type='intf', but doxygen marks it up as type='cl'.   Given the keywords and conflicting terminology between ObjC and Java, the confusion is quite understandable.

2. Doxygen appends "-p" to the name of protocols.  This needs to be stripped off when the name appears in the TokenIdentifier element.
Comment 1 Peter 2008-10-20 04:39:41 UTC
Created attachment 120901 [details]
Sample header and Tokens.xml file show incorrect markup
Comment 2 Dimitri van Heesch 2008-10-21 18:20:51 UTC
Confirmed. I'll correct these in the next subversion update.
Comment 3 Dimitri van Heesch 2008-12-27 14:12:56 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.5.8. 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).
Comment 4 Peter 2009-03-05 02:00:02 UTC
I just tested the attached test header with 1.5.8.  The 2 significant items I highlighted in the bug description have been fixed, but all the other symbols in the header are still marked up incorrectly.  Sorry for not making it clear that there were more than these 2 issues being reported.

More highlights of things going wrong...

3. Global constants and enums are being marked up as C++ symbols instead of plain C (eg, myGlobalConstant and myEnum).

4. Instance methods of a class should have the type "instm", but doxygen is using "intfm", which is the type used to identify instance methods of a protocol.

5. Static/class methods of a class should have the type "clm", but doxygen is using "intfm" again.

6. Properties are all getting marked as C++ symbols.

7. Member methods and properties of protocols are using a <Scope> name identifing the protocol, but it still uses the "-p" version of the protocol name.
Comment 5 Peter 2009-07-29 17:50:28 UTC
Created attachment 139493 [details] [review]
Proposed patch that fixes all the issues

This patch fixes all the issues I report in this bug.  It is based on the latest files in the subversion repository: "Release-1.5.9-20090720".
Comment 6 Dimitri van Heesch 2009-08-12 08:44:13 UTC
Thanks for the patch. I'll include it in the next update.
Comment 7 Dimitri van Heesch 2009-08-20 10:13:11 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).