"Warning: Unable to resolve function...", Breathe omits param names?

[aprotyas]

I've been trying to get some documentation to build but I'm repeatedly stuck with the warning:

Unable to resolve function "b" with arguments (void*, int (*)(void*, void*)) in doxygen xml output for project "API" from directory: ../doc_output/xml.
Potential matches:
- void b(void *ptr, int (*comp)(void*, void*))

If you notice in the warning message, it is trying to match a description stripped off parameter names with a fully-formed description. Is there a reason why there is this discrepancy? I believe if parameter names are not omitted or stripped out, I wouldn't see this warning.

Here's a small example to reproduce the problem with: https://github.com/wjwwood/breathe_unable_to_resolve_function_mvp
Note that this issue is exhibited for breathe>4.26.0 only.

---

At first, I thought it was an issue with whitespacing, because Breathe's sensitivity to whitespaces came up in a discussion in svenevs/exhale#98, but no amount of whitespace adjustment could resolve the warning. Also, FYI, I am not using exhale in the workflow that generates this warning.

[jakobandersen]

The white-space sensitivity shouldn't exist in Breathe any more. Both the argument to doxygenfunction and the potential matches extracted from the XML are parsed and then the parameter names are (supposed to be) removed.
In this case the logic failed on parameters that are function pointers, but #723 should fix that particular case. There are definitely a few more complicated examples that would fail as well, but if you find some that are not listed in #723, then please let me know.

[aprotyas]

Thanks for the quick response about this! I don't have any specific cases that would be targeted by #723 at the moment, but I'll be sure to report back to you.
There are other cases of "unresolved function" warnings, but it's hard to determine where in the sphinx/breathe/exhale stack the error is introduced. One such case is svenevs/exhale#113.

[jakobandersen]

That one is another case for #723: the noexcept should be stripped as well before parameter comparison.