Autolinks to functions do not take effect in @name scope and file scope.

[st-masa]

Describe the bug

From 1.9.5, some patterns of Links to functions are not linked.

1. <functionName>"("<argument-list>")" -> not linked
2. <functionName>"()" -> not linked
3. "::"<functionName> -> not linked
4. (<className>"::")n<functionName>"("<argument-list>")" -> linked
5. (<className>"::")n<functionName>"("<argument-list>")"<modifiers> -> not checked... but maybe linked
6. (<className>"::")n<functionName>"()" -> linked
7. (<className>"::")n<functionName> -> linked

Expected behavior
All patterns of links are linked correctly.

Screenshots

To Reproduce

Extract the attachment AutolinksToFunctionsSample.zip and execute doxygen with its DoxyFile.

    @details
    - Link to namespaceFunction(int arg1, int arg2) without reference cmd. 
    - Link to namespaceFunction() without reference cmd.
    - Link to ::namespaceFunction without reference cmd and brackets.
    - Link to namespaceFunction without reference cmd and brackets. (not autolinked by design.)
    - Link to @ref namespaceFunction(int arg1, int arg2) with reference cmd.
    - Link to @ref namespaceFunction() with reference cmd.
    - Link to @ref namespaceFunction with reference cmd but without brackets.
    - Link to sample::namespaceFunction(int arg1, int arg2) without reference cmd.
    - Link to sample::namespaceFunction() without reference cmd.
    - Link to sample::namespaceFunction without reference cmd and brackets.
    - Link to @ref sample::namespaceFunction(int arg1, int arg2) with reference cmd.
    - Link to @ref sample::namespaceFunction() with reference cmd.
    - Link to @ref sample::namespaceFunction with reference cmd but without brackets.

Version
1.9.5 on Windows 10 (64 bit) and MacOSX.
Maybe other OS should be the same.

Additional context

The refactored getDefsNew() in Refactoring: reimplement getDefs using symbol resolver seems to cause this issue.

[albert-github]

I think the results as shown by doxygen i.e.

is correct as the namespaceFunction is located in the namespace sample and in the given lines there is no reference to this namespace neither is there in the header file header.h. I think that in the documentation the word classname should maybe extended a bit so it includes namespace names as well.
I think the result from the 1.9.5 version is even better as here we get the extra warning:

header.h:18: warning: unable to resolve reference to 'namespaceFunction()' for \ref command

[st-masa]

Thank you for advising.
As you mentioned, AutolinksToFunctionsSample.zip's function links without namespace should not be linked because of their ambiguities.

I have created another sample which contains two classes with same-named methods.
AutoLinkSample2.zip

Links below @name command cause warnings like:

sample1.h:84: error: explicit link request to 'Function2()' could not be resolve

And function links sample1_8h.html and sample2_8h.html are not enabled.

If header.h file is added to INPUT, the warnings do not happen.

[st-masa]

When too many header files are set toINPUT, I observed some autolink symbols are not linked even though configured LOOKUP_CACHE_SIZE = 9.
(using previousgetDefsOld it is ok.)

But, it's not easy to make minimized sample to reproduce...

[albert-github]

I have my doubt about the links ::Function2() etc though as I understood this should go to the global namespace, but in this case there is nothing of that kind (the file header.h is excluded.

Even with the getDefsOld I still see one message (per file), though all links look like to go to sensible places.

@doxygen any idea?

[doxygen]

Looks like the main problem is that the member group documentation (i.e. the documentation associated with @name) is rendered twice, once for the namespace documentation and once more for the file documentation. The links in the file documentation were incorrectly evaluated in file context (thus requiring a fully qualified names in order to be resolved and incorrectly resolving to global functions of the same name if present).

A secondary problem was that the line numbers of the warnings were incorrect, because the end of the member group marker /// @} was overwriting the "start" line number of the documentation block.

Both problems should be addressed in the attached commit. So please verify if this indeed fixes the problem.

[st-masa]

@doxygen
Thank you for the fix.
I have verified the issue posted here is fixed.

As of now, I do not come up with ideas to reproduce the issue posted here.
So I will file another issue if I can find how to reproduce.

[doxygen]

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

[luftaquila]

<functionName>"()" form still does not linked at 1.9.6