False positive: rule community-delphi:UnusedConstant

[simonegirlanda]

Prerequisites

• This bug is in SonarDelphi, not SonarQube or my Delphi code.
• This bug has not already been reported.

SonarDelphi version

1.15.0

Delphi version

10.4

SonarQube version

10.7

Issue description

We are having hundreds of this false positive, on constants, but also on other elements.
The problem isn't easy to replicate, some time the problem disappear, apparently without intentional changes.
I was able to isolate the problem in the attached unit.

In this specific case, constant declared in line 7, is used in line 50.

Steps to reproduce

execute code analysis on the attached unit.

Minimal Delphi code exhibiting the issue

unit SistemaFrm;

interface

const
CM_CREATE_RECUR = WM_USER + 10000;

type
TcxCheckGroupAccess = class(TcxCheckGroup);
TSistemaForm = class(TAnagForm, IDckExplorerChildForm)

procedure   AggiuntiSingoliEventiRipetitivi( AEvent: TcxSchedulerControlEvent);

end;

var
SistemaForm : TSistemaForm;
aNewEvent : Boolean;

implementation

{$R *.dfm}

procedure TSistemaForm.AggiuntiSingoliEventiRipetitivi( AEvent: TcxSchedulerControlEvent);
var
afield : Variant;
begin
if not Assigned(AEvent) then // event deleted or not created
Exit;

if AEvent <> Nil then
try
if True then begin

  inherited;

  // Aggiorno la descrizione dell'evento con il codice del punto di prelievo
  //afield := aEvent.GetCustomFieldValueByName('cal_ptoPrelievo');
  if Not(Varisnull(Afield))
     then aEvent.Caption := aField
     else ;
  if AEvent.IsRecurring and (AEvent.EventType = etPattern) then Begin// Is the parent event
    // Prima inserisco l'evento padre ... e poi inserisco tutte le sue occorrenze
    aEvent.Caption := aField;
    //aEvent.AllDayEvent := False;
    PostMessage( Self.Handle, CM_CREATE_RECUR, 0, AEvent.ID);
  end
end;

Finally
end;
end;

begin
registerclass(TSistemaForm);
end.

[cirras]

Hi @simonegirlanda,

My thinking is that one of the arguments to PostMessage has an unresolved type and is causing name resolution failures for the whole invocation.

Some questions:

• does your scan complete without warnings/errors?
• if you run your scan with debug logging enabled (-X flag) are there any unresolved units (with an X next to them in the tree)?

[simonegirlanda]

Ciao @cirras thank you for your answer

My thinking is that one of the arguments to PostMessage has an unresolved type and is causing name resolution failures for the whole invocation.

ok thanks, I'll check.

Scan was made with -X, apparently no related errors/warnings, just this one:

18:04:13.834 WARN  Missing blame information for the following files:
18:04:13.835 WARN    * AreaEnteQ/FORMS/SistemaFrm.pas
18:04:13.835 WARN  This may lead to missing/broken features in SonarQube

[simonegirlanda]

sonar.log

[simonegirlanda]

@cirras I confirm that the false positive is related to the way the constant is used.

adding this instruction:

variable := CM_CREATE_RECUR

solve the issue.
after removing the instruction the error is issued again.

[cirras]

Hi @simonegirlanda,

Looking at your scan log made me realize that your "minimal example" has no uses clauses and therefore isn't valid/compilable code.

It's pretty much guaranteed that things will go wrong in the analysis if you're missing necessary imports.

Please:

• provide a compilable example
• provide a new scan log

[simonegirlanda]

Hi @cirras the "minimal example" supplied is an extract from our original source code that is valid/compilable and where we receive the same false positive.

I will produce a new compilable example with a new scan.

Thank you for your support.

[cirras]

Hi @simonegirlanda,

Any luck with a new reproduction case?

[simonegirlanda]

No. :-(

If I write a minimal compilable example, I have no issue.
We got these kind of issues only in our original complex code (both compilable and not compilable) with tons of uses.
No errors or warning in the logs.

These are very annoying issues, we will spend some more time next week to try to find a root cause.

[EduardoVaz06]

I've also been seeing lots of false positives, both in UnusedConstantCheck and UnusedLocalVariable.

One example is this one (I simply added new lines in the already existant test)

As it seems the false positive happens when the constant/variable is used as a parameter in a method call or similar.

[cirras]

Hi @EduardoVaz06,

As in the case above, we need the reproduction case to be compilable code. The analyser won't be able to resolve the Canvas.TextRec method in your test because you haven't declared a Canvas variable.

If the method call cannot be resolved, then none of the arguments will be resolved or recognised as used.

There are different reasons why an invocation might not be resolved. A common one is that the sonar project has been configured incorrectly, and some units/imports are unavailable to the analyzer as a result. This causes name resolution failures.

Bugs in the analyzer are also possible - we've fixed several in this upcoming release alone. Name resolution (and invocation/overload resolution) is complicated and the exact rules are not documented. If you believe that your false positives are the result of a genuine bug in the analysis engine and not a misconfiguration, we really need to see a minimal reproduction case that compiles.

[cirras]

I've raised #377 to improve the situation (in all rules - including UnusedConstant and UnusedLocalVariable) when symbol information is incomplete.

Note that this doesn't make your symbol information any more complete than it already was.

Please look over your project configurations carefully and ensure:

• your .dproj files are included by sonar.sources
• the following properties are set correctly:
  • sonar.delphi.toolchain
  • sonar.delphi.compilerVersion
  • sonar.delphi.installationPath
• all relevant source code is present in the scan environment and at the correct path
  • including third party source code
  • the analyzer does not support scanning compiled DCUs

If things still don't seem quite right and you're continuing to see false positives, I would be happy to look over any new minimal reproducible cases in a new issue.

This issue will be closed once #377 is merged.