I want to use the Coverage plug-in for Jenkins for a C++ project. In said project I use Squish Coco to generate a code coverage report in Cobertura format which is then fed to the recordCoverage step of the Coverage plugin.

In the project, there are several functions each containing several lambdas with the same signature (which is pretty common in C++, I suppose). Since those lambdas are also instrumented, they land up in the Cobertura file which, when being passed to the recordCoverage step in a Jenkins pipeline, causes an error of type:
java.lang.IllegalArgumentException: There is already a child [METHOD] calculate::[lambda][](int) <0> with the name calculate::[lambda][](int) in [CLASS] calculate <1, LINE: 100.00% (1/1)>
This already happens for example for the following function:

int calculate(int value) {
    auto plusTwo = [](int x) { return x + 2; };
    auto timesTwo = [](int x){ return x * 2; };
    return timesTwo(plusTwo(value));
}

When instrumented, tested, and converted to a Cobertura file, this creates the following snippet inside the latter:

<class name="calculate" filename="Calculate.cpp" lineRate="1.0" branch-rate="1.000000" complexity="">
  <methods>
    <method name="calculate::[lambda]" signature="[](int)" line-rate="1.0" branch-rate="1.000000">
      <lines>
        <line number="53" hits="3" branch="false"/>
      </lines>
    </method>
    <method>
      <method name="calculate::[lambda]" signature="[](int)" line-rate="1.0" branch-rate="1.000000">
      <lines>
        <line number="54" hits="3" branch="false"/>
      </lines>
    </method>
  </methods>
</class&gt;

One should note that the only difference in the Cobertura file between both lambdas is their line number. This snippet supposedly causes the parser error which, in turn, causes the whole pipeline step to fail. This parsing error is quite unfortunate since such code with several lambdas in the same scope is by no means exotic or rare.

One can make the parser ignore this error by using the ignoreParsingErrors option of the recordCoverage step but this still causes two kinds of problems:

1. The skipped parser errors are still written to the output which makes them hard to differentiate from actual hard errors.
2. The generated Coverage report is still faulty since every lambda skipped by such a parsing error counts as "not covered" even if the Cobertura file says otherwise.

It would therefore be desirable to either have the parser fixed to not count this scenario as error or at least have an option (or adjust the existing one?) to work around this issue by at least still providing the correct metrics in the end.