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 403017 - Multiple enums with the same name confuse Doxygen
Multiple enums with the same name confuse Doxygen
Status: RESOLVED OBSOLETE
Product: doxygen
Classification: Other
Component: general
1.5.1
Other All
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
[moved_to_github]
Depends on:
Blocks: 173045
 
 
Reported: 2007-01-31 23:01 UTC by Stewart Gordon
Modified: 2018-07-30 11:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stewart Gordon 2007-01-31 23:01:09 UTC
Please describe the problem:
If two enums in different modules (in D code at least) have the same name, Doxygen treats them as one enum and documents it twice.

Steps to reproduce:
Create two D modules that define an enum with the same name.  Example:

----- multi_enum_1.d -----
enum Enum4 {
	VALUE1,  //!< first value of multi_enum_1.Enum4
	VALUE2,  //!< second value of multi_enum_1.Enum4
	VALUE3   //!< third value of multi_enum_1.Enum4
}
----- multi_enum_2.d -----
enum Enum4 {
	VALUE4,  //!< first value of multi_enum_2.Enum4
	VALUE5,  //!< second value of multi_enum_2.Enum4
	VALUE6   //!< third value of multi_enum_2.Enum4
}
----------

Try running it through doxygen.


Actual results:
HTML output looks like this:

enum   Enum4 {
         VALUE1, VALUE2,
         VALUE3, VALUE4,
         VALUE5, VALUE6
       }

Enumeration Type Documentation

enum Enum4

Enumerator:
    VALUE1  first value of multi_enum_1.Enum4
    VALUE2  second value of multi_enum_1.Enum4
    VALUE3  third value of multi_enum_1.Enum4
    VALUE4  first value of multi_enum_2.Enum4
    VALUE5  second value of multi_enum_2.Enum4
    VALUE6  third value of multi_enum_2.Enum4

Thus the pages generated from multi_enum_1.d and multi_enum_2.d are identical except for the filename in the heading.

Expected results:
In each case, document only those members that are actually part of that enum in that source file.

Does this happen every time?
Yes

Other information:
I haven't checked to see if multiple classes, structs, unions, etc. with the same name suffer from the same problem.
Comment 1 cyberwan 2007-11-14 15:32:20 UTC
I have this C# code :

public class Log

public class WebLog : Log
{
    public enum Event
    {
        event1,
        event2
    }
}

public class AcqLog : Log
{
    public enum Event
    {
        event2,
        event3
    }
}


which gives me the following documentation :

Class WebLog
  enum WebLog::Event
    event1
    event2
    event2
    event3

Class AcqLog
  enum AcqLog::Event
    event1
    event2
    event2
    event3

The enums seem correctly identified, except that they contain the join of the enums contents. If I rename the enums as WebEvent and AcqEvent, then it works fine.

I also tried to delete the inheritance, but the error is the same.

It seems that enums with the same name, whereas they are placed in different namespaces, are filled with the content of all their homonyms...

Hope this helps
Comment 2 Dimitri van Heesch 2007-11-14 18:22:30 UTC
cyberwan: your problem is different from the orginal report (where both enums where in the same names), and should already be fixed? Did you try it with doxygen version 1.5.4?
Comment 3 Stewart Gordon 2007-11-14 20:41:36 UTC
This has helped to shed some light on the matter.  If the enums are in differently named classes, Doxygen correctly distinguishes them.  I've also found that if I add explicit module declarations to my original testcase, then Doxygen recognises that they are distinct.  I've also tried putting them in same-named classes in different modules; again, whether it's handled correctly depends on the presence or absence of implicit module declarations.

So the bug is that, Doxygen fails to distinguish enums in different modules in the absence of explicit module declarations.  In D, every source file is a module, its identity being the filename minus extension unless overridden by a module declaration.  That is, a file qwert.d acts as though it begins with

    module qwert;

unless a module declaration gives it to be something else.  Doxygen doesn't correctly implement this aspect of D.
Comment 4 Stewart Gordon 2007-11-14 22:55:40 UTC
(In reply to comment #3)
> This has helped to shed some light on the matter.  If the enums are in
> differently named classes, Doxygen correctly distinguishes them.  I've also
> found that if I add explicit module declarations to my original testcase, then
> Doxygen recognises that they are distinct.  I've also tried putting them in
> same-named classes in different modules; again, whether it's handled correctly
> depends on the presence or absence of implicit module declarations.

I meant to say presence or absence of _explicit_ module declarations.  But it's probably the same thing.  Essentially, it's whether the module declarations are implicit or explicit.
Comment 5 André Klapper 2018-07-30 11:02:03 UTC
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!