\ref fails to resolve reference to a member of a struct nested in a class template specialization (C++)

[krivenko]

Describe the bug

Doxygen 1.9.5 introduced a regression which affects \ref's ability to resolve members of structures that are defined within a class template specialization.

/// Outer class template
template<bool B, typename T> class Outer {};

/// Specialization of Outer
template<typename T> class Outer<true, T> {

public:
    /// Inner structure
    struct Inner {
        /// Data member
        int x;

        /// Return
        /// 1. @ref Outer<true, T>::Inner::x
        /// 2. @ref Inner::x
        /// 3. @ref x
        int get_x() const { return x; }
    };
};

Doxygen 1.9.4 generates correct links from all the 3 instances of @ref here, while 1.9.5 fails to do so.

issue.hpp:14: warning: unable to resolve reference to 'Outer<true, T>::Inner::x' for \ref command
issue.hpp:15: warning: unable to resolve reference to 'Inner::x' for \ref command
issue.hpp:16: warning: unable to resolve reference to 'x' for \ref command

The exact commit where the regression was introduced is b290399.

Expected behavior

Proper link generation, the way it was in 1.9.4.

To Reproduce

ref_struct_in_class_spec.zip

Version

Doxygen 1.9.5 (b290399*)
Gentoo Linux x86_64
Doxygen built from git sources, GCC 13.2.1

[albert-github]

Problem is also still present in the current master 1.11.0 (48a3670)

[doxygen]

@krivenko Please verify if the referenced commit fixes the problem for you. Do not close the issue, this will be done automatically when the next official release becomes available.

[krivenko]

@doxygen Thank you for the quick response!

The example I posted gives the expected result with db523de. That said, I still cannot make Doxygen generate correct links in my own project.

It turns out, the problem still manifests itself with a slightly more complex example where everyting is placed in a namespace.

namespace ns {

/// Outer class template
template<bool B, typename T> class Outer {};

/// Specialization of Outer
template<typename T> class Outer<true, T> {

public:
    /// Inner structure
    struct Inner {
        /// Data member
        int x;

        /// Return
        /// 1. @ref ns::Outer<true, T>::Inner::x
        /// 2. @ref Outer<true, T>::Inner::x
        /// 3. @ref Inner::x
        /// 4. @ref x
        int get_x() const { return x; }
    };
};

}

(Doxygen 1.9.4 still works fine here).

[doxygen]

@krivenko Thanks for the feedback. Adding the namespace indeed revealed some issues with the fix. I've pushed another commit, which should hopefully address these. Let me know if it works in your project now.

[albert-github]

@doxygen
By chance I ran yesterday in a, probably, similar problem with the worker 5.0.1 package from Fossies.
When running with 1.11.0 (dc6385c) I get here:

.../worker_types.cc:42: warning: no matching file member found for
unsigned int WorkerTypes::getAvailListColsSize
Possible candidates:
  'unsigned int getAvailListColsSize()' at line 53 of file .../worker_types.h
.../worker_types.cc:47: warning: no matching file member found for
int WorkerTypes::getAvailListColEntry(WorkerTypes::listcol_t type)
Possible candidates:
  'int getAvailListColEntry(listcol_t type)' at line 54 of file .../worker_types.h

A small example: example.tar.gz

[doxygen]

@albert-github The issue in example.tar.gz has a different cause (The redundant struct keyword in the struct A N::B construct was seen as struct A N: making the scanner go off-track looking for a base class), but since it is reported here, I've added the fix for it here as well.

[albert-github]

The problem for "worker_types" has been solved.
Running the full package again I saw another (probably similar one, but I'm happy with it when I have to write a new issue for it) in "fiellistview":

.../fieldlistview.cc:2473: warning: no matching class member found for
  void FieldListView::setSelectHandler(void(*nsh)(FieldListView *, int p))
Possible candidates:
  'void FieldListView::setSelectHandler(void(*nsh)(FieldListView *, int element))' at line 121 of file .../fieldlistview.h
  'void FieldListView::setSelectHandler(std::function< void(FieldListView *, int element) > cb)' at line 122 of file .../fieldlistview.h

Example: example_4.tar.gz

[doxygen]

@albert-github Yes, please create a different issue. Without trying the example, I can already see the problem is the parameter matching on function pointers. Doxygen sees void(*)(FieldListView *, int p) as the type of the variable, and this type does not match void(*)(FieldListView *, int element) because of the difference in parameter names that are embedded in the type. This is a known limitation of function pointer matching.

[krivenko]

@krivenko Thanks for the feedback. Adding the namespace indeed revealed some issues with the fix. I've pushed another commit, which should hopefully address these. Let me know if it works in your project now.

@doxygen Thanks a lot, I can now confirm that 1cbe096 solves the issue for me.