typedef of a function incorrectly output in HTML and PDF

[Albrecht-S]

Describe the bug
The following C++ code

  typedef int (Int_Function2)(int, int);

generates the wrong output:

  typedef int() Int_Function2(int, int);

Note the extraneous () after int.

A function typedef w/o (), for instance typedef int Int_Function2(int, int); works as expected. This could be used as a workaround but that wouldn't solve the issue. The project I'm working on has lots of typedef's using the former syntax.

Expected behavior
Output should be

  typedef int Int_Function2(int, int);

Screenshots
Please see PDF file with more comments:
Function_Typedef.pdf

To Reproduce
Self contained example:
typedef.tar.gz

Version
This issue is visible in doxygen 1.10.0, self-built from git master, commit a3cba26, but also in earlier releases. I don't think it's a regression in recent releases (but I may be wrong with this).
Platform: Linux, Debian 12 (Bookworm), included system doxygen version is 1.9.4.
Tested also with doxygen 1.8.14 (same effect).

Additional context
Related issues: #10136, #9944, #7060. All these seem to indicate problems parsing typedefs, particularly function typedefs with redundant () as in my example. I went back until about July 2018 to find similar issues (found these three mentioned issues).

The example posted above uses by default the smallest code to show the issue with (a) correct and (b) failing typedef. Both syntax variants are IMHO legit.

I found even more issues when I used different typedef's, some from the cppref site (see included example code). You can enable more examples by setting the macro MORE_EXAMPLES to 1 as indicated in the included source file test1.cxx. One of the examples from cppref uses a comma-separated list of typedef's that shows even more - only loosely related - issues (incorrect type propagation from one element of the list to later elements). I wanted to mention these here since I found these issues and they seem to be related.

Thanks for this great tool and I appreciate the work all devs are putting into it.

[Albrecht-S]

@albert-github Thanks for reading and for classifying it as a bug.

[doxygen]

This is also listed as known problem here (see bullet starting with "Redundant braces can confuse doxygen in some cases").

Probably in this particular case something is possible, but it is a very hard problem in the general case without proper type analysis which doxygen does not do (and often cannot do in case the input is incomplete).

[doxygen]

@Albrecht-S Please verify if the referenced commit fixes the issues you found. Do not close the issue, this will be done automatically when the next official version is released.

[Albrecht-S]

@doxygen Yep, current master (tested: c29b0e6) works as expected. From my POV this issue is fixed. Suggestion: please check if the related issues in my original post are fixed as well and close if appropriate.

Thank you very, very much for the quick fix.

Current master also fixes the following list of typedef's which had issues in 1.9.8:

/** more complicated typedef's. */
typedef int int_t, *intp_t, (&fp)(int, long), arr1_t[10];

Since the fix is in master, is it correct to assume that it will be in 1.10.0 which is the current version info of master ?

[albert-github]

Since the fix is in master, is it correct to assume that it will be in 1.10.0 which is the current version info of master ?

This is correct

[albert-github]

Good suggestion to check the related issues:

• Incorrect parsing of a typedef #9944 this looks to me as solved
• How to document functions passed as arguments ? #10136 I think this is still wrong
• Function pointer typedefs render strangely in HTML documentation #7060 I think this is still wrong.

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.10.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).

[Albrecht-S]

@doxygen I confirm that my issue is fixed in 1.10.0 (self-built from Git tag Release_1_10_0). I verified the fix with the provided demo project and with the original FLTK project (locally, not yet on the official FLTK server).

Thanks for fixing it.