Fehler in FixInsight? (W521)

[freimatz]

Delphi-Quellcode:

unit FixInsight;

interface

implementation

type
  TEnum = (dummy1, dummy2);

function TestFixInsight(): TEnum;
begin
  Exit(TEnum.dummy1)
end;

end.

FixInsight meldet "[FixInsight Warning] FixInsight.pas(10): W521 Return value of function 'TestFixInsight' might be undefined".
Ist das ein Bug?

[Stevie]

Schaut so aus, wenn du aber das Semikolon hinter dem Exit machst, dann verschwindet das false positive.

P.S. Geht auch mit anderen Typen:

Delphi-Quellcode:

function Foo: Integer;
begin
  Exit(42)
end;

Hab es mal an Roman gemeldet.

[freimatz]

Ah, Danke.
Die Methode bei der das bei uns zuerst aufgetreten ist war wesentlich umfangreicher. Nachdem ich es geschafft hatte uses zu vermeiden kam ich nicht mehr auf die Idee, dass die Umgehung des Problems so einfach ist.

[bytecook]

Da gibts momentan noch mehr Probleme, speziell mit den erweiterten Records:

[FixInsight Internal] uSVFXDataCore.pas(149): Fatal parser error: <'Colon' expected found ';'>

Code:

  TSVFXDataSourceAction = Record
    ActionId : TSVFXDataAction;
    Value : TMemoryStream;
    class operator Initialize (out Dest: TSVFXDataSourceAction);  <================ Zeile 149
    class operator Finalize (var Dest: TSVFXDataSourceAction);
    class operator Assign (var Dest: TSVFXDataSourceAction; const [ref] Src: TSVFXDataSourceAction);
  end;

Zitat von Stevie:

Hab es mal an Roman gemeldet.

Hi Stevie, ist das noch [e-mail]?

[freimatz]

Auch hier finde ich die Umgehung des Problems sehr einfach - man verwende neue Sprachfeatures erst in der über-, über-, (über-?) nächsten Version

[bytecook]

Zitat von freimatz:

Auch hier finde ich die Umgehung des Problems sehr einfach - man verwende neue Sprachfeatures erst in der über-, über-, (über-?) nächsten Version

Das ist nicht lustig!

[Uwe Raabe]

Zitat von bytecook:

Das ist nicht lustig!

Vor allem ist das auch kontraproduktiv. Damit wird dem Tool-Anbieter (hier Roman) doch nur suggeriert, dass man das mangels allgemeinen Interesses nicht berücksichtigen braucht.

[Stevie]

Zitat von bytecook:

Da gibts momentan noch mehr Probleme, speziell mit den erweiterten Records

Hat eher was mit DelphiAST zu tun, was das noch nicht versteht. Kannste also hier reporten: https://github.com/RomanYankovsky/DelphiAST

Aber hey - nicht mal die IDE selbst versteht diesen Code

[himitsu]

Zitat von Stevie:

Aber hey - nicht mal die IDE selbst versteht diesen Code

Wenn LSP alles sofort kennen würde, weil der Entwickler Compiler und Das parallel und gleichzeitig entwickeln täte (oder im Compiler das auch benutzen würde und es deswegen funktionieren muß) und man für solche Parser darauf aufbaut (unbekannte Knoten überspringend/unverändert/unbehandelt lasen) dann wäre die Welt bestimmt viel einfacher und es würde bei neuen Sprach-Features nicht gleich abrauchen.

[Stevie]

Zitat von himitsu:

Wenn LSP alles sofort kennen würde, weil der Entwickler Compiler und Das parallel und gleichzeitig entwickeln täte (oder im Compiler das auch benutzen würde und es deswegen funktionieren muß) und man für solche Parser darauf aufbaut (unbekannte Knoten überspringend/unverändert/unbehandelt lasen) dann wäre die Welt bestimmt viel einfacher und es würde bei neuen Sprach-Features nicht gleich abrauchen.

Das ist ja der langfristige Plan, aber da kommt man nunmal nicht von 0 auf 100 hin - selbst MS hat für Project Roslyn Jahre gebraucht.
Derzeit werkeln immer noch verschiedene Parsermechanismen in der IDE, class completion wird noch nicht vom LSP gefüttert - deshalb fällt das auch derzeit komplett auseinander, wenn man nen custom managed record in der Unit hat.

Witzige Geschichte: durch die Diagnose der LSP Logdateien bzgl eines argen Speicherverbrauchs wurde neulich ein Fehler gefunden, dessen Fix auch die Compiler Performance verbessert, da im LSP Prozess derselbe Code werkelt, der auch im Compiler sitzt. Es gibt also Licht am Ende des Tunnels, auch wenn der Tunnel noch lang ist