Recent

Author Topic: Compiler messes up the String type when FCL gtree is used  (Read 1850 times)

trexet

  • New Member
  • *
  • Posts: 37
Compiler messes up the String type when FCL gtree is used
« on: July 17, 2024, 01:36:46 am »
For some unknown reason, the compiler (3.2.2, laz 3.4) seems to forget about the String type in the methods definition when the TTree from FCL gtree unit is used.

The exact conditions:
1) The gtree's TTree is used by any means (by making a TTree field or specializing a type)
2) The program has more than 1 class with methods which take a String argument (the classes may be independent, or one inherited from other). The broken methods are all except the first one defined.

What does not fix the problem:
1) Setting mode either ObjFPC or Delphi
2) Setting the {$H+} switch before the uses section
3) Setting the {$H+} switch in the gtree and all of it's dependencies (gvector, gstack, gqueue, gdeque)
4) Doing Clean and Build

What does fix the problem:
1) Setting the {$H+} switch after the definition of the first method that uses String argument (which stays undamaged)

What does not cause the problem:
1) Using TTreeNode from gtree
2) Using other FCL units (checked gvector and gpriorityqueue)

Example:
Code: Pascal  [Select][+][-]
  1. program project1;
  2.  
  3. {$mode ObjFPC}{$H+}
  4.  
  5. uses gtree;
  6.  
  7. type
  8.  
  9.     TDumbTreeData = record
  10.         Value: Integer;
  11.     end;
  12.  
  13.     TDumbTree = class
  14.         Tree: specialize TTree<TDumbTreeData>;
  15.     end;
  16.  
  17.     TEntity1 = class
  18.         Name: String;
  19.         constructor Create(_Name: String);
  20.     end;
  21.  
  22.     TEntity2 = class
  23.         Name: String;
  24.         constructor Create(_Name: String);
  25.     end;
  26.  
  27. constructor TEntity1.Create(_Name: String);
  28. begin
  29.     Name := _Name;
  30. end;
  31.  
  32. constructor TEntity2.Create(_Name: String);
  33. begin
  34.     Name := _Name;
  35. end;
  36.  
  37. begin
  38.  
  39. end.
  40.  
Quote
project1.lpr(32,22) Error: function header doesn't match any method of this class "constructor Create(ShortString);"
project1.lpr(24,21) Error: Found declaration: constructor Create(AnsiString);

Here, it can be fixed by writing {$H+} at the line 31.

UPD: figured out that this problem is not reproduced on a Linux system, but does occur on a fresh Windows installation with fresh Lazarus

Also, having 1 class is enough - it's about the methods:
Code: Pascal  [Select][+][-]
  1. program project1;
  2. {$mode ObjFPC}{$H+}
  3. uses gtree;
  4. type
  5.  
  6.     TDumbTreeData = record
  7.         Value: Integer;
  8.     end;
  9.     TDumbTree = class
  10.         Tree: specialize TTree<TDumbTreeData>;
  11.     end;
  12.  
  13.     TEntity1 = class
  14.         Name: String;
  15.         constructor Create(_Name: String);
  16.         procedure DoStuff(Arg: String);
  17.     end;
  18.  
  19. constructor TEntity1.Create(_Name: String);
  20. begin
  21.     Name := _Name;
  22. end;
  23.  
  24. procedure TEntity1.DoStuff(Arg: String);
  25. begin
  26. end;
  27.  
  28. begin
  29. end.
All methods except the first one gets their String argument to be ShortString in the definition.
« Last Edit: July 17, 2024, 04:00:45 pm by trexet »

jamie

  • Hero Member
  • *****
  • Posts: 6733
Re: Compiler messes up the String type when FCL gtree is used
« Reply #1 on: July 17, 2024, 04:51:02 am »
may not be the issue but, think I read somewhere about inlining the types
Code: Pascal  [Select][+][-]
  1.   TDumbTree = class
  2.         Tree: specialize TTree<TDumbTreeData>;
  3.     end;
  4.  
  5. // change to
  6.   TDumbTree = class
  7.    Type  TMyTree = Speciialize TTree<TDumbTreeData>;
  8.      Puiblic
  9.         Tree: TMyTree;
  10.     end;
  11.  

That was hand written so it could be sloppy.
and it may not fix your issue.
The only true wisdom is knowing you know nothing

TRon

  • Hero Member
  • *****
  • Posts: 3618
Re: Compiler messes up the String type when FCL gtree is used
« Reply #2 on: July 17, 2024, 07:05:13 am »
Dunno what to say:

Code: Bash  [Select][+][-]
  1. $ fpc -B project1.pas
  2. Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling project1.pas
  6. gvector.pp(101,22) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:QWord;" marked as inline is not inlined
  7. gvector.pp(104,34) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:QWord;" marked as inline is not inlined
  8. gdeque.pp(239,3) Note: Local variable "i" not used
  9. Linking project1
  10. 39 lines compiled, 0.2 sec
  11. 3 note(s) issued
  12.  
Perhaps something off in your project settings ?
This tagline is powered by AI

cdbc

  • Hero Member
  • *****
  • Posts: 1644
    • http://www.cdbc.dk
Re: Compiler messes up the String type when FCL gtree is used
« Reply #3 on: July 17, 2024, 07:33:25 am »
Hi
Hmm, you're sure it is this exact project, listed in your first post?!?
Code: Pascal  [Select][+][-]
  1. program project1;
  2.  
  3. {$mode ObjFPC}{$H+}
  4.  
  5. uses gtree;
  6.  
  7. type
  8.   TDumbTreeData = record
  9.     Value: Integer;
  10.   end;
  11.  
  12.   TDumbTree = class
  13.     Tree: specialize TTree<TDumbTreeData>;
  14.   end;
  15.  
  16.   TEntity1 = class
  17.     Name: String;
  18.     constructor Create(_Name: String);
  19.   end;
  20.  
  21.   TEntity2 = class
  22.     Name: String;
  23.     constructor Create(_Name: String);
  24.   end;
  25.  
  26. constructor TEntity1.Create(_Name: String);
  27. begin
  28.   Name := _Name;
  29. end;
  30.  
  31. constructor TEntity2.Create(_Name: String);
  32. begin
  33.   Name := _Name;
  34. end;
  35.  
  36. begin
  37.   writeln('what?'); // <--- This added by me
  38. end.
And the result:
Code: Bash  [Select][+][-]
  1. [bc@hp gtree_str_error]$ fpt.sh project1.pp
  2. Free Pascal Compiler version 3.3.1-15019-g664f8fc2ba-dirty [2024/01/28] for x86_64
  3. Copyright (c) 1993-2024 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling project1.pp
  6. gvector.pp(106,22) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:System.QWord;" marked as inline is not inlined
  7. gvector.pp(109,34) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:System.QWord;" marked as inline is not inlined
  8. gvector.pp(217,3) Note: Local variable "def" is assigned but never used
  9. Linking project1
  10. 39 lines compiled, 0.2 sec, 159840 bytes code, 64528 bytes data
  11. 3 note(s) issued
  12. [bc@hp gtree_str_error]$
  13.  
...Had some good 'Ganja' lately, have you?!?  :D
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE5 -> FPC 3.2.2 -> Lazarus 2.2.6 up until Jan 2024 from then on it's: KDE5/QT5 -> FPC 3.3.1 -> Lazarus 3.0

trexet

  • New Member
  • *
  • Posts: 37
Re: Compiler messes up the String type when FCL gtree is used
« Reply #4 on: July 17, 2024, 02:23:23 pm »
...Had some good 'Ganja' lately, have you?!?  :D
Me not, but my compiler sure did
« Last Edit: July 17, 2024, 02:29:49 pm by trexet »

cdbc

  • Hero Member
  • *****
  • Posts: 1644
    • http://www.cdbc.dk
Re: Compiler messes up the String type when FCL gtree is used
« Reply #5 on: July 17, 2024, 03:01:06 pm »
Hi
Just checked in fpc 3.2.2:
Code: Bash  [Select][+][-]
  1. [bc@hp gtree_str_error]$ fpc project1.pp
  2. Free Pascal Compiler version 3.2.2 [2023/06/16] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling project1.pp
  6. gvector.pp(101,22) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:QWord;" marked as inline is not inlined
  7. gvector.pp(104,34) Note: Call to subroutine "function TVector<project1.TTreeNode<project1.TDumbTreeData>>.Size:QWord;" marked as inline is not inlined
  8. gdeque.pp(239,3) Note: Local variable "i" not used
  9. Linking project1
  10. 39 lines compiled, 0.2 sec
  11. 3 note(s) issued
  12. [bc@hp gtree_str_error]$ ./pr
  13. project1       project_trunk  
  14. [bc@hp gtree_str_error]$ ./project1
  15. what?
  16. [bc@hp gtree_str_error]$
  17.  
edit:
Mind you, without the added line "writeln('what?'); // <--- This added by me", I can't compile in either of the 2 compilers. compiles either way.
Regards Benny
« Last Edit: July 17, 2024, 03:04:44 pm by cdbc »
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE5 -> FPC 3.2.2 -> Lazarus 2.2.6 up until Jan 2024 from then on it's: KDE5/QT5 -> FPC 3.3.1 -> Lazarus 3.0

trexet

  • New Member
  • *
  • Posts: 37
Re: Compiler messes up the String type when FCL gtree is used
« Reply #6 on: July 17, 2024, 03:30:00 pm »
Target OS: Linux for x86-64
Maybe a windows specific problem?
I'm going to quickly make a Win10 VM with a fresh Lazarus installation and test it.

If it would work fine, then I suppose my installation is somehow broken :(

UPD: Yes, the issue is present with a fresh new installation on a fresh new Windows system
« Last Edit: July 17, 2024, 03:54:35 pm by trexet »

jamie

  • Hero Member
  • *****
  • Posts: 6733
Re: Compiler messes up the String type when FCL gtree is used
« Reply #7 on: July 17, 2024, 10:58:11 pm »
If it makes you feel any better, I can also reproduce it on 3.2.2
The only true wisdom is knowing you know nothing

VisualLab

  • Hero Member
  • *****
  • Posts: 569
Re: Compiler messes up the String type when FCL gtree is used
« Reply #8 on: July 18, 2024, 12:21:51 am »
I tested the code provided by trexet. I use:
  • OS: Windows 10 64-bit,
  • IDE: Lazarus 3.4 64-bit.

The code provided by trexet does not compile. The compiler reports an error as reported by trexet. Lazarus view after compilation shown in the attached screenshot. I am also attaching the project code.

TRon

  • Hero Member
  • *****
  • Posts: 3618
Re: Compiler messes up the String type when FCL gtree is used
« Reply #9 on: July 18, 2024, 08:36:30 am »
Indeed affirmative when cross-compiling from Linux to Windows (which I originally did not test).

edit: seems really specific to windows as I tried different other targets (ppc, arm32, arm64, m68k) with many other OS' which all compile without issues. win32 exhibits the same erroneous behaviour.

fwiw: I did not test trunk because mine is out of date and does not have a windows cross-compiler installed.
« Last Edit: July 18, 2024, 08:59:48 am by TRon »
This tagline is powered by AI

VisualLab

  • Hero Member
  • *****
  • Posts: 569
Re: Compiler messes up the String type when FCL gtree is used
« Reply #10 on: July 18, 2024, 12:07:05 pm »
I did one more test in which I slightly modified the code. Fields of the TEntity1 and TEtity2 classes placed in their private section. Now the code compiles. I am attaching the Lazarus view after compilation and the project code.

Thaddy

  • Hero Member
  • *****
  • Posts: 16135
  • Censorship about opinions does not belong here.
Re: Compiler messes up the String type when FCL gtree is used
« Reply #11 on: July 18, 2024, 01:02:00 pm »
For windows and windows only try this at the end of your unit:
Code: Pascal  [Select][+][-]
  1. {$ifndef unix}// or ifdef mswindows...maybe better.
  2. initialization
  3.    SetMultiByteConversionCodePage(CP_UTF8);
  4. finalization
  5.    SetMultiByteConversionCodePage(CP_ACP);
  6. {$endif}
If I smell bad code it usually is bad code and that includes my own code.

trexet

  • New Member
  • *
  • Posts: 37
Re: Compiler messes up the String type when FCL gtree is used
« Reply #12 on: July 22, 2024, 10:35:25 pm »
For windows and windows only try this at the end of your unit:
Code: Pascal  [Select][+][-]
  1. {$ifndef unix}// or ifdef mswindows...maybe better.
  2. initialization
  3.    SetMultiByteConversionCodePage(CP_UTF8);
  4. finalization
  5.    SetMultiByteConversionCodePage(CP_ACP);
  6. {$endif}
What if the program is not a unit and has no initialization/finalization sections?
Are you sure that using runtime routines would fix a compilation issue?

 

TinyPortal © 2005-2018