Neuer FixInsight ist da!

[Der schöne Günther]

I don't know about this DelphiAST, but what about the other way around? Just parse as you always do. We now have a list of warnings and the line number it occurred on.

So in case the code goes like this

Delphi-Quellcode:

25:   procedure TChild.someVirtualMethod();
26:   begin
27:       // No quack at all
28:   end;

, there is a W519 raised for line 25. Now before outputting our results to the IDE's listbox, let's check line 25 whether it contains a comment with an exclamation mark followed by "W519".

So if the code is like

Delphi-Quellcode:

25:   procedure TChild.someVirtualMethod(); //!W519 because FixInsight is smart
26:   begin
27:       // No quack at all
28:   end;

, there will be no "false positive".

[Roman Yankovsky]

Nice idea

[jaenicke]

This could even be expanded to the whole unit scope (for example for 3rd party units, where only the first line would have to be modified then):

Delphi-Quellcode:

unit Example; //!W519 (cannot be fixed because of...)
...

[Roman Yankovsky]

Finally FixInsight 2015.10 is able to suppress a warning for a piece of code (that was discussed on a previous page). It works not for a scope, but for a particular line though.

Example:

Delphi-Quellcode:

      procedure RestartTimer;
      begin
        FTimer.Enabled := False;
        FTimer.Enabled := True; //FI:W508 - this warning will be ignored.
      end;

So it's just a "FI:<RULENUMBER>" comment.

[Der schöne Günther]

Neat! That is WAY better than using IFDEF blocks

[Roman Yankovsky]

I would like to announce Christmas bundle. FixInsight and Parnassus Navigator go together.

http://sourceoddity.com/blog/2015/12...sus-navigator/

[Der schöne Günther]

I have updated from 2015.10 to 2015.11 and would like to report a few things:

Fatal Parse error
caused by the following code:

Delphi-Quellcode:

function TSomeClass.calcSomething(const someCount: Integer): Integer;
begin
   Result := 'REG11111;2;33333333;44444444;55555555'.Length * someCount; // <-- This line
   [...]
end;

This did not cause a fatal error in 2015.10

C110: Getter or setter name is different from property declaration
The following code causes a C110. I guess it's because of the "&":

Delphi-Quellcode:

      public property
         &Register[index: TRegisterIndex]: TRegisterValue
            read getRegister
            write setRegister;
            default;

W521 Return value of function might be undefined
The following code did not cause this warning in 2015.10:

Delphi-Quellcode:

type TSomeEnum = (uno, dos, tres);

function TSomeClass.getSomeValue(): TSomeEnum;
begin
   if someCondition() then
      Exit(TSomeEnum.uno)
   else
      if someOtherCondition() then
         Exit(TSomeEnum.dos)
      else
         Exit(TSomeEnum.tres);
end;

O802 ResourceString is declared but never used
That's an excellent idea!

W528: Variable not used in for-loop
This is strange one. The following code produces a W528:

Delphi-Quellcode:

unit Unit1;

interface uses System.Generics.Collections, System.SysUtils;

type

   TPair = System.Generics.Collections.TPair<Single, Single>;
   TPairs = TArray<TPair>;

   TPairsExporter = class
      public class function DataAsString(const pairs: TPairs): String;
   end;

implementation uses System.Classes;

class function TPairsExporter.DataAsString(const pairs: TPairs): String;
var
   stringBuilder:   TStringBuilder;
   pair:          TPair;
begin
   stringBuilder := TStringBuilder.Create();
   try
      for pair in pairs do
         stringBuilder.Append(pair.Key).Append(sLineBreak);

      Result := stringBuilder.ToString();
   finally
      stringBuilder.Destroy();
   end;
end;

end.

.

If you remove the ".Append(sLineBreak)", the warning is gone. Oh, and please ignore the fact that using a for..in with records was not the best idea

[Stevie]

Trag die Sachen doch einfach in den offiziellen bugtracker ein.

[Der schöne Günther]

Consider the following:

Delphi-Quellcode:

   IFirstInterface = interface
      procedure doStuff();
   end;

   ISecondInterface = interface
      procedure doStuff();
   end;

   TImplementation = class(TInterfacedObject, IFirstInterface, ISecondInterface)
      procedure doStuff();
   end;

Compiles and works fine (unlike other languages). But probably not what you want. I know about method resolution clauses and how to get around it. But I would like to get a warning that this does not look right at all.

Opinions?