Beim Error-Insight hab ich eher den Verdacht, als wenn da ein anderer Parser genutzt wird, als für den Compiler.
Mit dem selben Parser und einem Background-Compiler (ohne aktive Codeoptimierungen und Co.) könnte man man da bestimmt etwas zusammenbekommen, welches besser läuft.
Nee, nicht den ganzen Compiler, nur etwas, was den Quellcode einließt und erstmal in eine Art
DOM-Objekt zerlegt.
Darüber könnte man auch endlich mal einen Multi-Pass-Compiler bauen (denn der aktuelle Single-Pass-Compiler mag vielleicht schneller sein, hat aber auch gewaltige Nachteile).
Wo man jetzt doch sowieso mehrere Compiler hat,
macht es sich eh besser, den Quellcode erstmal zu zerlegen, darin vielleicht noch ein paar optimierungen vorzunehmen und kann es dann an den entsprechenden Compiler weitergeben, der ja nun selber keinen Code mehr parsen muß (da alles schon geparst und syntaktisch kontrolliert vorliegt) und somit sich nur noch auf seine wesentliche Aufgabe konzentrieren zu braucht.
Für's Code-Insight und das Error-Insight kann man sich dann aus ganz einfach das Wichtigste rausziehen, aus den den vorgeparsten Daten.
Da sich die Syntax ständig verändert/erweitert hätte man dann einen Parser, welcher auch wirklich mit allen Codes klar kommt, da er auch von denen kommt, welche die Syntax festgelegt haben.
Die letzen Delphi-Parser stammen doch quasi noch aus Delphi 7-Zeiten und danach gibt es kaum noch etwas, was wirklich mit all den neueren Feinheiten von Generics, Operatoren, recordmethoden, Klassenvariablen oder alternativen recordstrukturen klarkommt.
Neueres ist doch mehr nur für einen begrenzten Wortschatz, von dazugehörigen "kleinen" Scriptengines, erstellt wurden.