Recent

Author Topic: PParser fails on "strict private" and types containing function references  (Read 697 times)

Bogen85

  • Full Member
  • ***
  • Posts: 146
The following is not understood:
Code: Pascal  [Select][+][-]
  1. type
  2.   tCleanupProc = reference to procedure;
  3.   tCleanup     = record
  4.   strict private
  5.     cleaner: tCleanupProc;
  6.     class operator finalize (var self: tCleanup);
  7.     class operator initialize (var self: tCleanup);
  8.     procedure assign (const _cleaner: tCleanupProc);
  9.   public
  10.     property x: tCleanupProc write assign;
  11.     procedure run;
  12.   end;

It fails on strict private.

Code: Text  [Select][+][-]
  1. EParserError: Expected "," or ":" at token "Identifier private" in file src/main.pas at line 15 column 10

It strict private is replaced with private then it fails on cleaner: tCleanupProc;

Code: Text  [Select][+][-]
  1. EParserError: Expected "," or ":" at token "Identifier cleaner" in file src/main.pas at line 17 column 5

This is all with Free Pascal Compiler version 3.3.1 [2022/09/26] for x86_64 on Linux.

The code in question that contains the above snippet compiles and runs fine.

I'll try to put together a complete example extracted from the program in question and file an issue concerning this, as PParser is part of FPC's FCL in fcl-passrc.

« Last Edit: October 01, 2022, 02:08:07 pm by Bogen85 »

Bogen85

  • Full Member
  • ***
  • Posts: 146
Well, it also can't parse an interface that starts out with this:

Code: Pascal  [Select][+][-]
  1. type
  2.   TAuto<T: class> = record

The code in question works fine...

ASerge

  • Hero Member
  • *****
  • Posts: 2032
It fails on strict private.
Did you add {$MODESWITCH ADVANCEDRECORDS}?

Bogen85

  • Full Member
  • ***
  • Posts: 146
The code question compiles and runs fine without {$MODESWITCH ADVANCEDRECORDS}

It is the PParser unit that can't parse it.

However, I added {$MODESWITCH ADVANCEDRECORDS}.

It compiles and runs as expected, but PParser unit still can't parse it.

So far PParser parses every other unit I've thrown at it, except for:
  • types with <T: class> in them
  • strict private
  • types with function references in them

I filed an issue on the first, types with <T: class> in them

https://gitlab.com/freepascal.org/fpc/source/-/issues/39931

PascalDragon

  • Hero Member
  • *****
  • Posts: 4749
  • Compiler Developer
So far PParser parses every other unit I've thrown at it, except for:
  • types with <T: class> in them
  • strict private
  • types with function references in them

I filed an issue on the first, types with <T: class> in them

https://gitlab.com/freepascal.org/fpc/source/-/issues/39931

Please also report issues for the others with example code.

Bogen85

  • Full Member
  • ***
  • Posts: 146
Please also report issues for the others with example code.

Working on it... Filed one for PParser fails on a record with strict private   https://gitlab.com/freepascal.org/fpc/source/-/issues/39935

I'm finding more problems with record parsing though (for items that work in class parsing).... Quite a few more...

Should I file individual bug reports?

I would prefer to file one will the all failing cases for records I'm finding. (Where the code with those records is working)
« Last Edit: October 01, 2022, 09:20:03 pm by Bogen85 »

PascalDragon

  • Hero Member
  • *****
  • Posts: 4749
  • Compiler Developer
Should I file individual bug reports?

I would prefer to file one will the all failing cases for records I'm finding. (Where the code with those records is working)

It should be separate issues as they might have different, underlying causes.

Bogen85

  • Full Member
  • ***
  • Posts: 146
Should I file individual bug reports?

I would prefer to file one will the all failing cases for records I'm finding. (Where the code with those records is working)

It should be separate issues as they might have different, underlying causes.

Alright, it will take a bit longer, but I will get them submitted. I may create one that has ALL the test cases I've found, then create individual reports for each of the issues, referring back to the common one. As I find new  faults, I'll update the common one, and add a submit a new issue, like with the others.

Is that acceptable?

PascalDragon

  • Hero Member
  • *****
  • Posts: 4749
  • Compiler Developer
Is that acceptable?

No, because each of the issues should have its own test case, after all it might be that one issue takes much longer to solve than another and then either the developer would need to extract a test case anyway or the fixes wouldn't be correctly tested until everything is fixed.

Bogen85

  • Full Member
  • ***
  • Posts: 146
Is that acceptable?

No, because each of the issues should have its own test case, after all it might be that one issue takes much longer to solve than another and then either the developer would need to extract a test case anyway or the fixes wouldn't be correctly tested until everything is fixed.

Understood!
Thanks!
I will get to them as I need these items addressed, it will just take a while.

 

TinyPortal © 2005-2018