C++ enums being defined in multiple files after b265433 (multi-thread input processing)

[swt2c]

Describe the bug
After upgrading to 1.8.20, I observed a problem where enums are being defined in multiple files (in addition to the one where they are actually defined). I bisected this behavior to b265433. This is the behaviour with b265433:

event_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
filename_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
headercol_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
index.xml:    <member refid="interface_2wx_2listctrl_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="event_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="filename_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="headercol_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="webkit_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="toplevel_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="regex_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
index.xml:    <member refid="utils_8h_1adf764cbdea00d65edcd07bb9953ad2b7ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
interface_2wx_2listctrl_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
regex_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
toplevel_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
utils_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>
webkit_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>

Expected behavior
This is the behaviour before b265433:

index.xml:    <member refid="webkit_8h_1aac34dfe6c6b73b43a4656c9dce041034ae1379fdf0911b272f03e8dc06c88b463" kind="enumvalue"><name>wxWEBKIT_NAV_LINK_CLICKED</name></member>
webkit_8h.xml:          <name>wxWEBKIT_NAV_LINK_CLICKED</name>

The enum value wxWEBKIT_NAV_LINK_CLICKED is only defined in webkit.h, so it should only show up in that XML file.

Version
Running on Fedora Linux 32. Compiled doxygen myself to bisect.

[swt2c]

I should clarify that these are unnamed enums, e.g.,:

enum {
    wxWEBKIT_NAV_LINK_CLICKED = 1,
    wxWEBKIT_NAV_BACK_NEXT = 2,
    wxWEBKIT_NAV_FORM_SUBMITTED = 4,
    wxWEBKIT_NAV_RELOAD = 8,
    wxWEBKIT_NAV_FORM_RESUBMITTED = 16,
    wxWEBKIT_NAV_OTHER = 32

};

It appears to be that in b265433 and beyond that all unnamed enum values (from multiple declariations) are being combined into a single unnamed enum during the parsing.

[albert-github]

I tried to reproduce this and after a number of tries I was successful (anonymous things are always tricky), in future:

please attach a, small, self contained example (source+configuration file in a tar or zip) that allows us to reproduce the problem? Please don't add external links as they might not be persistent.

It looks like the anonymous enums are all put on one heap.
The output of the 1.8.18 version:

The output of the 1.8.20 (and also of the current master63dc5b9b1b3e8fb875304a954e4df934b249034b of August 26, 2020) version:

The project I used: example.tar.gz

[swt2c]

Thanks @albert-github - I was working on a SCCCE, but hadn't been successful in creating one yet. Thank you!

[doxygen]

Please verify if the commit (9d9d085 ) fixes the problem. Don't close the bug report yet.

[swt2c]

I can confirm this fixes the issue. 👍 Thanks a lot for the quick fix!

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.0.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).