include GUI test sources in selfchecks

[firewave]

No description provided.

[firewave]

I added those as there's a passedByValue false negative in testcppchecklibrary. Also more dogfooding is always good.

I did suppress the naming-privateMemberVariable warnings since they would have caused almost all lines in the source to be changed.

The uninitMemberVar are not of interest since the classes are simply mocked.

[firewave]

I need to suppress all the warnings from an include. I would expect this to work but it doesn't as it was probably not intended to be used that way. I will file a ticket about it.

[firewave]

I filed https://trac.cppcheck.net/ticket/14219 about being able to suppress the uninitMemberVar warnings per implementation

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

@chrchr-github Looks like we have false positives when a function is not implemented:

gui/projectfile.h:345:61: style:inconclusive: Function 'addSuppression' argument 1 names different: declaration 'suppression' definition '<unnamed>'. [funcArgNamesDifferentUnnamed]
    void addSuppression(const SuppressionList::Suppression &suppression);
                                                            ^

[chrchr-github]

@chrchr-github Looks like we have false positives when a function is not implemented:

But it is implemented here: https://github.com/firewave/cppcheck/blob/70e4ea3b850d73f4ed120d54a2b3c637edc79653/gui/projectfile.cpp#L787
Still looks like some kind of FP though.

[firewave]

But it is implemented here:

The GUI tests mock these classes and only implement what is necessary to get them to link.

[firewave]

So we have drive-by detection of https://trac.cppcheck.net/ticket/10670 now - so hopefully we should be able to package that into a separate check.

[chrchr-github]

But it is implemented here:

The GUI tests mock these classes and only implement what is necessary to get them to link.

There is no warning for this, so not sure what`s going on:

struct S {
    void f(int i);
};

[firewave]

There is no warning for this, so not sure what`s going on:

I will have a look tomorrow.

[firewave]

The warnings originate from gui/test/resultstree/testresultstree.cpp which mocks the function calls. So we lack the information in the warning about the location of the unnamed parameter.

And in this case it is in intentional since the parameters are not being used (I possibly pointed out this case in the PR which introduced these warnings).

These warnings also cannot be properly suppressed because they are reported at the declaration and thus the annotation needs to be added in the header. This is another case where we need to report them on the implementation instead. This also makes sense in the case that there might be various implementations of the functions which might not all experience the same issue.