Code navigation fails with generics

Original Reporter info from Mantis: MageSlayer @MageSlayer

• Reporter name: Denis Golovan

Description:

Hi

Lazarus code navigation stops on following code.
Error in "Messages" window is:
Error: expected >, but TVI found

...

type
  generic TVI<T> = record
    v:T;
    ix:NativeInt;
    class operator > (const a:TVI; const b:TVI): boolean;inline;
    class operator = (const a:TVI; const b:TVI): boolean;inline;
    class operator <= (const a:TVI; const b:TVI): boolean;inline;
    class operator >= (const a:TVI; const b:TVI): boolean;inline;
  end;
  generic TVISet<T> = class(specialize TheBTreeSet<specialize TVI<T>>);
...

Looks like last line is not correctly parsed (but compiled ok).

Additional information:

Tested under Linux x64, Lazarus svn. rev 59970

Mantis conversion info:

• Mantis ID: 34824
• Version: 2.1 (SVN)
• Fixed in revision: r62693 (#d1b15edc), r63137 (#1c9deb7a), 63148 (#9aa25f1b), 63149 (#eb33c352).
• Monitored by: » soerensen3 (soerensen3)

assigned to @lazidealist

added CategoryFCL ResolutionDuplicate Version2.1 (SVN) WS: GTK 2 labels

Converted from Mantis. Note by Denis Golovan @MageSlayer

• Mantis submitter username: MageSlayer @MageSlayer
• Mantis submitter real name: Denis Golovan

---

Still fails.
Tested in Lazarus svn. 61340

Converted from Mantis. Note by Juha Manninen @JuhaManninen

• Mantis submitter username: JuhaManninen @JuhaManninen
• Mantis submitter real name: Juha Manninen

---

Denis, your code does not compile. I tested with FPC trunk from ~ 2 months ago, using {

mode objfpc}{

H+}.
Does it compile with some other compiler version?
The message is:
unit1.pas(44,5) Fatal: Syntax error, "END" expected but "CLASS" found

Please provide compilable code, then we can look at codetools problems.

Converted from Mantis. Note by Denis Golovan @MageSlayer

• Mantis submitter username: MageSlayer @MageSlayer
• Mantis submitter real name: Denis Golovan

---

Small example attached.
Tested under Lazarus svn rev.61603 and FPC svn rev.42987

Converted from Mantis. Note by Juha Manninen @JuhaManninen

• Mantis submitter username: JuhaManninen @JuhaManninen
• Mantis submitter real name: Juha Manninen

---

Ok, {$modeswitch advancedrecords} was the essential thing. Now it compiles and I get the same error from codetools.
I must detach myself. I don't know how to fix this one.

[Edit]
The syntax is strange. Why does FPC accept it? There are 2 nested "specialize" clauses but the inner one "specialize TVI&LtPos;T>" does not really specialize anything. It still has the "T" there.
Maybe I just don't understand generics enough...

Converted from Mantis. Note by soerensen3

• Mantis submitter username: soerensen3
• Mantis submitter real name: soerensen3

---

generic TVISet&LtPos;T> = class(specialize TheBTreeSet&LtPos;specialize TVI&LtPos;T>>);
@juha Manninen
if you specialized the generic above the nested generic is also specialized and resolves to this:
specialize TVISet< Integer >;
resolves to
class(specialize TheBTreeSet&LtPos;specialize TVI&LtPos;Integer>>);

I think the error is in PascalParserTool somewhere in lines 6070+, after checking for unit name.
Maybe it needs to check for '<' after the identifier or specialize keyword as first identifier (depending on mode delphi or objfpc). There it might be necessary to recursively call TPascalParserTool.ReadSpecialize again. Sorry I don't understand CodeTools enough to make the change myself.

Please note that in mode objfpc the optional unit identifier comes before the specialize keyword.
In Mode Delphi the nested specialization goes like this:
type TypeName = UnitNameCanBeDotted.TypeName < UnitNameCanBeDotted.TypeName < UnitNameCanBeDotted.TypeName >>;
In Mode Objfpc the equivalent would be:
type TypeName = UnitNameCanBeDotted. specialize TypeName < UnitNameCanBeDotted. specialize TypeName < UnitNameCanBeDotted.TypeName >>;

I would be very happy if this was fixed! Thanks in advance!

Converted from Mantis. Note by soerensen3

• Mantis submitter username: soerensen3
• Mantis submitter real name: soerensen3

---

It seems that the attached changes fixed the problem for me.

Explanation: A generic specialization parameter is basically a type reference so no need to reinvent the wheel.

I did not notice any negative side effects yet but please someone review this patch before pulling it into trunk.

Converted from Mantis. Note by Juha Manninen @JuhaManninen

• Mantis submitter username: JuhaManninen @JuhaManninen
• Mantis submitter real name: Juha Manninen

---

Yes the patch fixes the issue and does not break anything. I applied it.
Thank you soerensen3! I guess you studied the Codetools for a while.

Notes about patches for the future:

1. Please remove old code instead of commenting it out. Old code can be found in commit history if needed.
   I removed it before the commit. The code became shorter and simpler. Good!

2. There was a 16 lines offset. I guess you used the released Lazarus version instead of trunk. Sometimes it can cause a conflict and a patch cannot be applied, thus trunk is recommended for all development.

$ cd components/codetools/
$ patch -p0 < ~/patch/fix-nested-generics-specialization.patch
patching file pascalparsertool.pas
Hunk # 1 succeeded at 6068 (offset 16 lines).
Hunk # 2 succeeded at 6085 (offset 16 lines).

Converted from Mantis. Note by soerensen3

• Mantis submitter username: soerensen3
• Mantis submitter real name: soerensen3

---

Thanks for applying. I worked a bit with Codetools but I wouldn't call me an expert.

I was working with trunk but I guess I did something wrong. This was my first patch.

Converted from Mantis. Note by Denis Golovan @MageSlayer

• Mantis submitter username: MageSlayer @MageSlayer
• Mantis submitter real name: Denis Golovan

---

Tested and works as expected.
Thanks a lot.

Converted from Mantis. Note by Mattias Gaertner @lazidealist

• Mantis submitter username: Mattias @lazidealist
• Mantis submitter real name: Mattias Gaertner

---

This patch broke some things.
Juha, there is a test suite for codetools. When applying a patch you can check it easily:
https://wiki.freepascal.org/Codetools#Test_suite

Converted from Mantis. Note by Mattias Gaertner @lazidealist

• Mantis submitter username: Mattias @lazidealist
• Mantis submitter real name: Mattias Gaertner

---

I reverted the patch in 63137.

Converted from Mantis. Note by Juha Manninen @JuhaManninen

• Mantis submitter username: JuhaManninen @JuhaManninen
• Mantis submitter real name: Juha Manninen

---

Ok, I will run the test suite in future.
Detaching myself ...

Converted from Mantis. Note by Pascal Riekenberg @PascalRiekenberg

• Mantis submitter username: PascalR @PascalRiekenberg
• Mantis submitter real name: Pascal Riekenberg

---

I think the patch is okay but other parts of codetools still rely on only getting identifiers as generic parameters.
I'll have a look and try to update those parts to get them working again.

Converted from Mantis. Note by Pascal Riekenberg @PascalRiekenberg

• Mantis submitter username: PascalR @PascalRiekenberg
• Mantis submitter real name: Pascal Riekenberg

---

Fixed. See attached patch.

Converted from Mantis. Note by Pascal Riekenberg @PascalRiekenberg

• Mantis submitter username: PascalR @PascalRiekenberg
• Mantis submitter real name: Pascal Riekenberg

---

Extended tests for nested specializations.

Converted from Mantis. Note by Mattias Gaertner @lazidealist

• Mantis submitter username: Mattias @lazidealist
• Mantis submitter real name: Mattias Gaertner

---

Thank You!

Converted from Mantis. Note by Denis Golovan @MageSlayer

• Mantis submitter username: MageSlayer @MageSlayer
• Mantis submitter real name: Denis Golovan

---

Retested in Lazarus svn. 65180.
Works fine. Thanks.

closed

locked this issue

Attached files:

• fix-nested-generics-specialization.patch (Size: 774 bytes, user: soerensen3 (), date: 2020-03-03)
• testcodecompletion.pas.patch (Size: 1595 bytes, user: PascalR (Pascal Riekenberg), date: 2020-05-13)
• pascalparsertool.pas.patch (Size: 4706 bytes, user: PascalR (Pascal Riekenberg), date: 2020-05-13)
• Generic-code-completion.tar.gz (Size: 14562 bytes, user: MageSlayer (Denis Golovan), date: 2019-12-30)

mentioned in issue #36981 (closed)

marked this issue as related to #23903 (closed)

marked this issue as related to #33788 (closed)

Duplicate of #33788 (closed)

marked this issue as related to #36494 (closed)