I wonder if I even should attempt to file a bug report against TParser, since it is not meant to be used as a true parser anyway. The class is basically only for dfm/lfm parsing.
So why the shakespearian title?
Well both Delphi and FPC versions of TParser
expose the same error and at the same spot.
Problem is:
- Delphi recovers
- Freepascal crashes
Sample code that is supposed to parse its own source:
program testrtlparser;
{$ifdef fpc}{$mode objfpc}{$H+}{$endif}
{$apptype console}
uses sysutils, classes;
var
fs: TFileStream;
pp: TParser;
begin
fs := TFileStream.Create('testrtlparser.pas', fmOpenread);// parse myself
try
pp := TParser.Create(fs);
try
repeat
case pp.token of
toSymbol:
writeln('symbol: ', pp.tokenstring);
toString:
writeln('string: ', pp.tokenstring);
toInteger:
writeln('integer: ', pp.tokenstring);
toFloat:
writeln('float: ', pp.tokenstring);
toWString:
writeln('widestring: ', pp.tokenstring);
else
// writeln(pp.tokenstring);
end;
pp.nextToken;
until pp.token = toEOF;
finally
pp.free;
end;
finally
fs.free;
end;
readln;
end.
Of course, if I add a try/except I get the same result as Delphi, with the same error in both flavors.
Why all the fuzz?
Simple, I have TParser derivative code (20+ years old) that parses uses clauses.
(It adds skiptoken, basically when it finds "uses" it copies all tokens upto the ';' pushes them into a stringtree and later try to recurse the lot. The real code is quite a lot more lines
)
BTW the first error is that if a $ is encountered it is prematurely interpreted as an integer, the second error is that if the next char is within a..f the rest of the token is ignored.
I am not quite sure the clean-rooming of almost two decades ago can explain why the exact same error exists in both flavors.... It is quite easy to fix.
Recent
