PParser fails on "strict private" and types containing function references

[Bogen85]

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.

[Bogen85]

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]

It fails on strict private.

Did you add {$MODESWITCH ADVANCEDRECORDS}?

[Bogen85]

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

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

[PascalDragon]

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

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

Please also report issues for the others with example code.

[Bogen85]

Please also report issues for the others with example code.

Working on it... Filed one for PParser fails on a record with strict private   **s://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)

[PascalDragon]

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]

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]

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]

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.