The INTAEditViewNotifier OTA enhancement in 10 Seattle allows drawing into the editor. This can be used to paint the messages directly into the editor.

This could be tricky to write, but would be a /very/ useful warning.

See, eg, http://stackoverflow.com/questions/4509015/should-the-compiler-hint-warn-when-passing-object-instances-directly-as-const-in

var
List : IList<Integer>; // A Spring4D list
...
FreeAndNil(List); // <- bam!

It shouldn't be possible to call Free since you can only call methods defined in an interface on an interfaced type, but FreeAndNil doesn't have any checking and will compile happily with the above code.

If you have a method which declares some constants, and those constants are not used, no warning is generated by Delphi.  IMO there should be a warning, just like for variables that are not used.

Eg,
procedure TForm1.Foo;
const
 A = 1;
 B = 2;
var
 C,
 D : Integer;
begin
 C := B;
 Caption := IntToStr(C);
end;

Delphi warns about unused variable D, but not unused constant A.

A constructor that calls another constructor in the same class leads to false positive W504.

type
TFoo = class(TObject)
public
constructor Create;
end;

TBar = class(TFoo)
public
constructor Create;
constructor CreateEx;
end;

//<- http://fixinsight.userecho.com/topic/701447-w504-false-positive-with-objects-inherited-from-tobject/
constructor TFoo.Create;
begin

end;

constructor TBar.Create;
begin
inherited Create;
end;

constructor TBar.CreateEx;//<- False positive W504
begin
Create;
end;

Objects like stringlists should be destroyed by .free; scan for .free for the object if not found flag it
(especially in destroy methods)

It can really lead in weird situations when you something like this

if LDoubleValue = 0.00 then

and should be changed to if SameValue(LDoubleValue, 0.00) then (Super simple case).

when you comparefloating point values are more than less dangerous. And finding them from code is more than less tedious job. Have to find out what the types being compared actually are. (did not check but how this is compiled if LDoubleValue >= LIntValue then... Is the Integer converted Float before compare, but still it might be epsilon away from the even integer value??)

Anyways this can lead to very subtle bugs in your code and very hard to debug and so on. I would predict that getting these out from the legacy code without helping hand is very hard work :)

It is quite possible / easy to construct an object by calling a classes' ancestor's constructor, instead of a constructor for the class you want to create. This leaves you with a partially constructed object, not a good thing.

One simple way to demonstrate this:

type
TFoo = class
constructor Create;
end;
TBar = class(TFoo)
protected // !
constructor Create(a : integer);
end;

// In another unit (!)
Bar := TBar.Create; // Calls TFoo.Create because TBar.Create is not visible outside the unit

I'd like a warning something like, "TBar has a constructor defined, but Bar is being constructed with ancestor class TFoo's constructor."

This is not quite as uncommon a circumstance as you might think - as well as the above, which would trip up any C++ programmer who would expect a compile error if it was calling the wrong constructor, there are also possibilities to do this when some but not all constructors are overridden, etc, too. I've seen bugs caused by this several times.

I don't know if it possible for FixInsight to detect his, but here is my use case.
I have two classes, TParent and TChild, and a class field in TChild hides a class field defined in TParent.

unit FixInsightTest;

interface

uses
  SysUtils,
  Classes;

type
  TParent = class(TPersistent)
  private
    fPrivate: string;
  protected
    fProtected: string;
  public
    fPublic: string;
  end;

  TChild = class(TParent)
  private
    fPrivate: string;   // this is fine, since it's private for this class
  protected
    fProtected: string; // class field hides class field of parent class
  public
    fPublic: string;    // class field hides class field of parent class
  end;

//
//  Tested with FixInsight 2015.04
//
//  This is somehow related to the warning W517, but this is a special case
//  because the current class' field hides a field of the parent class
//
//    "W517 Variable '%s' hides a class field, method or property"
//

implementation

end.

In some cases it is desired to have an empty else, except, ... block.

The suggestion is to relax the rule under certain conditions. One condition would be that the empty block contains a comment, which hopefully explains why the block is empty.

Visually this could look like the following:

(X) W501 Empty EXCEPT block
    (X) Accept comments
(X) W502 Empty FINALLY block
    ( ) Accept comments

with the above setting for the following code example:

procedure yeah(something, crazy:integer);
begin
  try
    try
      something := crazy div 0;
    except
      // we can safely swallow the exceptions here
    end;
  finally
    // nothing to clean up
  end;
end;

Fixinsight would not warn about the empty exception, but warn about the empty finally block