Unexpected warning against to QT code based on c++ programming language - Build Wrapper Analysis

Clean Code Report False-positive / False-negative...
, ,
1

Rule: cpp:s824 ==> Move this function declaration outside of this block scope

Current behavior: Sonarqube produces unexpected warning against to code written in QT frameworks based on c++ programming language.

Expected behavior: Sonarqube should not produce warning for function invoking through emit macro. Here would require to exclude this rule check only when emit is used.

Please share your recommendation - how to modify the behavior of this rule check only when emit macro is used (custom rule).

Build configuration: Build wrapper used with cmake

Description:
Function is declared in header file (header.h), and invoked in .cpp file using emit which QT macro. But sonar anlysis consider it as declaration instead invoking of function which is already declared in header.h file. Looks like it is wrong warning.

xxxheader.h file

namespace xxx_model {
class xxxxWarningModel : public QObject
{
    Q_OBJECT
signals:
    void onxxxxxChanged();


}}

xxxwarningmodel.cpp

#include "xxxheader.h"
#include <QDebug>

/**
 * Constructor for class
 *
 * @param [in] Default - QObject
 *
 * @return void
 */
namespace hmi_model {
xxxWarningModel::xxxWarningModel(QObject *parent)
    : QObject{parent}
{
    connect(this, &xxxWarningModel::onxxxDataChanged, this, &xxxWarningModel::xxxxFailure);
}

 * @return None
 */
void project_model::xxxWarningModel::updatexxxValue(const uint8_t &pvalue)
{
    QMutexLocker locker(&m_mutex);
    m_xxxFailure = pvalue;

    qInfo() << "XXX Failure received Mode:" << m_xxxFailure;
    emit onxxxxxChanged();
}
2

Is this behavior depends on build configuration to analyzer ??

We used build wrapper for analysis, any point that such wrong warnings can be avoided in compilation database ??

As per my understanding, emit macro is being considered as function declaration keyword ‘void’ at the time of rule checks. which supposed do not considered like that.

3

@community manager, could you please share some clue on how to handle/isolate warning reported in this ticket… ?
It is absolutely unexpected warning in our use case in QT framework…

  1. Create custom quality profile for c++ project - Completed
  2. Need to disable existing rule in custom quality profile which produces this error - Aware/Todo
  3. Need to write custom rule which should just ignore function invoke using emit keyword - need some support
  4. Need to enable custom rule in custom quality profile - Aware/To Do
4

Hello @community,

Could you please update on our request for c++ custom rule creation ?

Regards,
Muthusamy IR

5

Hey @muthusamy.ir,

Sorry for the late reply.

Also, please avoid jumping between topics. You started by reporting a false positive, let’s investigate that. Not sure how you reached custom rule creation.

If emit is a macro, it should be detected by our analyzer and not treated as an unknown type. Let’s investigate if it is not detected and why.

  • Which SonarQube version are you using?
  • Can you share the full analysis logs? If you prefer to share them privately, I can send you a private message.

Thanks,

7

Hello @Abbas ,

We are using Enterprise EditionVersion 9.9.1.
Please text me in private chat, I will share analysis logs in PM.

Why I switched to custom rule?
I thought of writing custom rule by modifying existing rule to ignore keyword/macro emit (using regex, etc…), hence new custom rule will ignore such function invoking using emit.

Regards,
R Muthusamy IR

8

Hi @muthusamy.ir,

I sent you a private message and you didn’t reply yet. Was the problem solved?

Thanks,

9

Hello Abbas,

Thanks for keeping eyes in this problem. Yes, we have got confirmation from project team that, issue is still persistent. I replied to you in original mail thread with team.

10

FYI, the issue was identified as a configuration issue: https://sonarsource.atlassian.net/browse/CPP-4770.

A workaround was provided privately and we will handle the ticket soon.

@muthusamy.ir Can you confirm that the false-positive disappeared after the workaround?

Thanks,

11

Hello Abbas,

We bypassed(ignored) the lines invokes emit function, which is false-positive and not fixable at development side.

Regards,

R Muthusamy Irungovel

MSDVC - DevOps

12

Hi @muthusamy.ir, please read my last private message to you. Your analysis is not configured correctly and will damage the quality of the analysis and not only this specific rule. I recommend trying to fix the configuration on your side until the ticket is handled on our side. If you have more questions on the workaround shared in PM, feel free to reach out.

14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.