Hello, I just joined this mailing list to mention an issue I found in Lazarus.

General description of the problem: Using new language features make working with Lazarus quite difficult.

The following wiki link outlines some of the new language features to the FPC bringing in compatibility with Delphi.

http://wiki.freepascal.org/FPC_New_Features_Trunk#Generic_records.2C_arrays_and_procedural_types

Using the new generic language below in Lazarus causes the IDE to generate continual Lazarus parser error messages in the message window. When these errors occur, Lazarus opens and switches to the offending file, highlighting the line such as "function GetEnumerator: IEnumerator<T>;". These errors messages and switching to the offending file occur anytime code insight is requested (ctrl+space) or whenever the object inspector row changes on the events tabs. Additionally you cannot add events to components when any unit links to a unit with offending code (example):

{$mode delphi}
type
  IEnumerable<T> = interface
    function GetEnumerator: IEnumerator<T>; // parser breaks here
continually
  end;
/path/unitname.pas(75,41) Error: expected end., but T found

The problem is that Lazarus's internal parser does not recognize the < in the line with "function GetEnumerator: IEnumerator<T>;" as a valid token, even though the code compiles with FPC 2.7.1 (trunk version) and {$mode delphi} perfectly fine.

Here are the details of my current Lazarus build:

Version: 0.9.31
SVN Revision: 32031
FPC Version: 2.7.1
i386-linux-gtk 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/05564913/attachment.html>

It is a known issue that it breaks in unusual ocasions. It also breaks if you use arm as your target processor.

You should use the bug tracker to report bugs.

Felipe Monteiro de Carvalho

2011/8/26 Anthony Walter

General description of the problem: Using new language features make working with Lazarus quite difficult.

I am happy to tell you that generics support in Lazarus IDE has improved just recently.
Please test with the latest trunk and report if you still find problems.

That is a quite recent Lazarus version. Are you sure you built it before testing?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/5b270ab6/attachment.html>

Yes,

there is a problem with generics + interface types.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/3d207a36/attachment.html>

2011/8/26 Juha Manninen :

there is a problem with generics + interface types.

And another one with "out":

http://bugs.freepascal.org/view.php?id=20060

2011/8/26 Felipe Monteiro de Carvalho

And another one with "out":

Looks like a poorly chosen identifier name. How could the build target affect codetools in such way?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/da4badff/attachment.html>

2011/8/26 Juha Manninen :

How could the build target affect codetools in such way?

The file is: /usr/share/fpcsrc/rtl/inc/softfpu.pp (aka software floating point implementation)

I am cross-compiling from linux-x86 to Android. Android is linux-arm with softfpu and eabi 5+.

Surely there are defines which make sure that softfpu.pp is not active in linux-x86, but is active in my Android cross-compiler. CodeTools somehow catches those defines. They are probably in the uses clause of the system unit.

2011/8/26 Felipe Monteiro de Carvalho

Right. I first thought the ultimate reason was the procedure var parameter named "out".
However it seems to work ok in other code.
Still, very poor name for a parameter. Think if it was defined as an out parameter.
It would be "out out: float64".

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/f3afe072/attachment.html>

2011/8/26 Juha Manninen :

Right. I first thought the ultimate reason was the procedure var parameter named "out". However it seems to work ok in other code.

For me it doesn't work. I just added to my TForm this:

public
  Procedure Something(out: Integer);

And pressed Ctrl+Shift+C

It fails.

?

Felipe Monteiro de Carvalho hat am 26.
August 2011 um 12:00 geschrieben:

"Out" as parameter name is not allowed in mode objfpc and delphi. The feature can be turned on/off with the modeswitch "out".? This needs to be implemented in the codetools.
I will take a look.?
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/4bac99e9/attachment.html>

26.08.2011 14:15, Mattias Gaertner ?????:

First, look please pascalparsertool.pas line 1175. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/2ad5875d/attachment.html>

System.pas does not declare any compiler mode, so:

http://www.freepascal.org/docs-html/prog/progse72.html#x271-286000D.1

It seams to use mode FPC

So if I understand correctly just removing FPC mode from that line would fix it =D I'll check.

thanks a lot,

It works =D

Mattias, can I commit?

Index: pascalparsertool.pas
=================================================================== --- pascalparsertool.pas (revision 32060)
+++ pascalparsertool.pas (working copy)
@@ -1172,7 +1172,7 @@

   begin
     // read parameter prefix modifier
     if UpAtomIs('VAR') or UpAtomIs('CONST') or UpAtomIs('CONSTREF')

- or (UpAtomIs('OUT') and (Scanner.CompilerMode in [cmOBJFPC,cmDELPHI,cmFPC]))
+ or (UpAtomIs('OUT') and (Scanner.CompilerMode in [cmOBJFPC,cmDELPHI])) then begin

       if not Extract then
         ReadNextAtom

?

Felipe Monteiro de Carvalho hat am 26.
August 2011 um 12:39 geschrieben:

It works =D Mattias, can I commit??

I'm sorry, but no.
As I wrote, it depends on the 'modeswitch out', not on the CompilerMode.? I implemented it. Please test.
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/a1a95dab/attachment.html>

2011/8/26 Juha Manninen

Yes, I'm sure. I installed Lazarus on Sunday using building it from source gotten from svn trunk. Also the SVN revision 32031 above is what the IDE says in my Lazarus->Help->About menu.

I reported the issue last night. It looks like it's been assigned here:

http://bugs.freepascal.org/view.php?id=20059
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/9d661f02/attachment-0001.html>

What about Delphi style generics not FPC style ones?

Regards,
Sven

2011/8/26 Mattias Gaertner :

I'm sorry, but no. As I wrote, it depends on the 'modeswitch out', not on the CompilerMode. I implemented it. Please test.

Thanks, it works =)

Since Juha Manninen mention in the bug tracker that he assigned this issue to himself and thaat it might not be gotten to in a while ... a quick question:

If I were to attempt to fix this issue myself, what is the fastest way to test my fixes to codetools short of rebuilding the entire IDE i.e. "make clean" from my Lazarus source directory? I ask because it takes quite a while (a minute or two) to do a "make clean".

Is there some way to just rebuild codetools and restart the IDE loading new version without things getting all out of whack (such as the IDE complaining that it can't find Interfaces.pp due to different compiled versions between some packages or something there about)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/6659f716/attachment.html>

Anthony Walter wrote

If I were to attempt to fix this issue myself, what is the fastest way to test my fixes to codetools short of rebuilding the entire IDE i.e. "make clean" from my Lazarus source directory? I ask because it takes quite a while (a minute or two) to do a "make clean".

I can make a cup of tea and drink it when I'm building, so what's a mere 2 minutes? ;-)

Is there some way to just rebuild codetools and restart the IDE loading new version without things getting all out of whack (such as the IDE complaining that it can't find Interfaces.pp due to different compiled versions between some packages or something there about)?

Build without packages?

Bart

2011/8/26 Anthony Walter :

If I were to attempt to fix this issue myself, what is the fastest way to test my fixes to codetools short of rebuilding the entire IDE i.e. "make clean" from my Lazarus source directory? I ask because it takes quite a while (a minute or two) to do a "make clean".

I usually do "make bigide", without doing make clean before it will go faster

I think that there is no solution. Having said that, 1 or 2 minutes for a large IDE is not a Qt might even take half
a day in a old machine.

Bart wrote

Build without packages?

And don't use the 'clean' option.

?

Anthony Walter hat am 26. August 2011 um 14:11 geschrieben:

You don't need to rebuild clean.?
Just rebuild the IDE using the IDE (tools / build lazarus). On recent computers this takes only a few seconds, because the IDE and FPC are clever enough to build only what has changed.?
?
Another option is to use one of the example projects in components/codetools/examples.?
?

?
Use less make and more IDE.?
?
?
Mattias
?
?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/fc7feb9c/attachment.html>

?

Felipe Monteiro de Carvalho hat am 26.
August 2011 um 14:20 geschrieben:

A make whatever is only needed after renaming important files. For example after an svn update you should this, because perhaps someone did rename something. Otherwise, you simply rebuild the IDE using the IDE. This is faster and will update third party components too.?
?
?

I think that there is no solution. Having said that, 1 or 2 minutes for a large IDE is not a Qt might even take half a day in a old machine.?

?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/4922ff46/attachment-0001.html>

2011/8/26 Anthony Walter

Such errors mean your system is broken somehow. Different versions of FPC or Lazarus maybe?

About fixing the bug yourself: good luck, honestly. Codetools is BIG and learning it may take some time. Don't get frustrated.

It is possible that Anton provides a patch for this issue or that Mattias (the author of codetools) fixes it.
Your new knowledge would still not be wasted because there are many other things to improve in Lazarus.

Regards
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/e3ac6cff/attachment.html>

2011/8/26 Juha Manninen

Well, I spent about 1 hour getting an external test going and replicating the issue using CodeToolBoss and attempting to JumpToMethod with offending code. I get the same error related to the ';' expected but 'T' found with a line like "function GetEnumerator: IEnumerator<T>;" inside an interface as a method.

I stepped through "TCustomCodeTool.ReadNextAtom;" for a while and looked at related code ... maybe 45 minutes, but still don't have a fix.

I have to do some real work for my boss guy (visual studio project), so I'll leave this issue for now, though if anyone wants to led me a hand on this (as a Lazarus newb) I'd be more than appreciative of your help/insights. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/c7aa2cba/attachment.html>

Okay I created a possible fix for this problem, though I'm not entirely sure if it's correct. This is my first contribution to any open source projects, so please take review changes with a bit of trepidation. You make want to also link to the issue with this code:

http://bugs.freepascal.org/view.php?id=20059

            // begin fix unit codetools/pascalparser
            // method: TPascalParserTool.ReadTilProcedureHeadEnd
            // insert at line number 1535
            // line above should be "end;"
            // Level: Integer is new local variable
            Level := 1;
            if GetAtom = '<' then
            begin
                ReadNextAtom;
                while True do
                begin
                    AtomIsIdentifier(true);
                    ReadNextAtom;
                    if CurPos.Flag = cafPoint then
                        Continue;
                    if CurPos.Flag = cafComma then
                    begin
                        ReadNextAtom;
                        Continue;
                    end;
                    if GetAtom = '<' then
                    begin
                        Inc(Level);
                        Continue;
                    end;
                    while GetAtom = '>' do
                    begin
                        ReadNextAtom;
                        Dec(Level);
                        if Level = 0 then
                            Break;
                        Continue;
                    end;
                    Break;
                end;
            end;
            // end fix
            // line below should be "end else begin"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110826/f0f6a28f/attachment.html>