Incorrect linking in C++ code

[albert-github]

In the CGAL project it was noted in an example that some instances of a function were hyperlinked (correct) and that some subsequent, identical, calls were not hyperlinked.
The, reduced, code looks like:

/** \file */

/// a fie
void fie()
{
  copy_face_graph (boost::make_function_output_iterator([&](const std::pair<TIN_with_info::Face_handle, Mesh::Face_index>& ff)
  {
    //{
      //color_map1 = CGAL::Color(1);
    //}
    if (ff.first->info() < 0)
      color_map2 = CGAL::Color(2);
    else
    {
      color_map3 = CGAL::Color(3);
    }
  }));
}

/// The NS
namespace CGAL
{
    /// the color class
    class Color
    {
      public:
        /// constructor
        Color(int);
    };
}

the result is:

Here the CGAL::Color on line 12 is hyperlinked but the CGAL::Color on line 15 isn't.
When removing the comment signs on the lines 8 - 10 all CGAL::Color ar hyperlinked.

I think the interesting rules in code.l are here:

<Body,FuncCall>"{" 

and

<MemberCall2,FuncCall>"{"

in the later block there is also a reference to the number of open round (() brackets.
Note also the double usage of the state: FuncCall.

As far as I can tell it is an unintended side effect from:

Commit: 0f01005b90986347e57a78c58585aea959da72a1 [0f01005]

Date: Friday, November 1, 2019 4:47:02 PM

i.e. the removal of g_bracketCount = 0; (now this would be yyextra->bracketCount = 0; in rule <MemberCall>{SCOPETNAME}/{BN}*"(")

@doxygen any idea what the best solution would be?

Doxygen version: 1.12.0 (e512970))
Example: example.tar.gz

[albert-github]

It looks a bit like that in the struct ctx of class callContext (in scopedtypevariant.h) besides the name and type also the bracketCount should be stored and used for comparison in case of theCallContext.popScope instead a test against 0.

A bit of a spoiling part might be though that also in case of a [ a push is used (and in case of ] a pop.

@doxygen So I'm not sure whether this would be the right approach.

[doxygen]

@albert-github The code was not really created with lambda's in mind. But I think you are right that storing and restoring the bracketCount would be a good solution direction to deal with starting new bodies (i.e. {...}) inside a call, so that the counter can be reset to 0 at the start of a block and restored to its original value at the end of the block.

[albert-github]

I've just pushed a proposed patch, pull request #11028

[albert-github]

Code has been integrated in master on GitHub (please don't close the issue as this will be done at the moment of an official release).

[doxygen]

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