giseldo/neodataset huggingface dataset:
Error with codetools


<h3><details><summary>Original Reporter info from Mantis: <small>Almindor</small></summary><small>

- **Reporter name:** Ales Katona
</small></details></h3>

## Description:

unit1.pas(8,51) Error: source not found: unit /home/ales/lazarus/lcl/units/x86_64-linux/graphics.ppu

reproduced with fpc 2.0.4 and 2.1.1

## Steps to reproduce:

Make new project, double click form

## Mantis conversion info:

- **Mantis ID:** 8407
- **OS:** Linux
- **OS Build:** 2.6
- **Platform:** x86_64
- **Version:** 0.9.21 (SVN)
- **Target version:** 0.9.22

Story points: 100.0
"Rescan FPC source directory" command does not work


<h3><details><summary>Original Reporter info from Mantis: <small>tsapi</small></summary><small>

- **Reporter name:** Tsvetoslav
</small></details></h3>

## Description:

Hi, with the recent SVN versions of Lazarus when I try to rescan FPC source directory using "Environment|Rescan FPC source directory" menu command, I receive the following error: <br/>
"The system.ppu was not found in the FPC directories. Make sure fpc is installed correctly and the fpc.cfg points to the right directory". <br/>
I have set the proper paths in Lazarus/Environment Options dialog, and also in my fpc.cfg file, but the error always occurs.<br/>
This happens in Windows and Linux

## Additional information:

I rised priority due to my personal feelings.Lazarus become pure editor without code tools working properly.Please correct priority if you don't agree with me.

## Mantis conversion info:

- **Mantis ID:** 8249
- **OS:** Win XP SP2; FC 6
- **Platform:** win32; linux
- **Version:** 0.9.21 (SVN)
- **Fixed in version:** 0.9.21 (SVN)
- **Fixed in revision:** 10551 (#cbb5dc8f80ad00944492942e4bb6038fa6cd79a5)
- **Target version:** 0.9.22

Story points: 100.0
closing form shown by ShowModal causing  a large flicker on background (parent) form


<h3><details><summary>Original Reporter info from Mantis: <small>forest</small></summary><small>

- **Reporter name:** Boguslaw Brandys
</small></details></h3>

## Description:

Closing form shown by ShowModal causing  a large flicker on background (parent) form.In fact it looks like background form is hidden and immediately shown - I could see other application through it during this small time (about 0.5 sec) :-( 

This problem was surely not inside official Lazarus 0.9.20 and SVN from December 2006 AFAIK.

## Steps to reproduce:

Check attached example.Put explorer window at background , run program click to show second form then close this form (which is shown modally).You will see that explorer window blink over project main form.

## Additional information:

r10338 and previous work good<br/>
r10339 changes to CloseModal caused this problem

## Mantis conversion info:

- **Mantis ID:** 8059
- **OS:** windows xp home
- **OS Build:** 32-bit
- **Build:** 10369
- **Platform:** windows
- **Version:** 0.9.21 (SVN)
- **Fixed in version:** 0.9.21 (SVN)
- **Fixed in revision:** 10370 (#49a9083bf9c3d8bfa73062bc1c22b4b672f142f0)
- **Target version:** 1.0.0
- **LazTarget:** 1.0

Story points: 100.0
Please implement multiple auto-uses units


<h3><details><summary>Original Reporter info from Mantis: <small>Almindor</small></summary><small>

- **Reporter name:** Ales Katona
</small></details></h3>

## Description:

When you make a package for Lazarus, only those units are added to uses section of a project which uses the package, which contain the main components.

It would be very nice to have the ability to add additional units per-component (or just per package) automatically to the uses section of a project.

For example: for lNet, I have lNetComponents unit which is added automatically if user adds any of my components on form. But in ALL cases I need the user to have visible types from unit lnet.pas (which is non-LCL/non-visual base unit of lNet).

Currently I circumvent this by delegating the types with TSome = lNet.TSome, and same goes for constants. I'd like to be able to have a list of units which get auto-added per component or at least per-package so when user uses lNet, his uses section automatically includes lNet.pas in uses section.

I think a per-component list of "additional auto-added units" would be best. So basically you 1st select the component in a combo-box somewhere in the main options of the package, and then you add any of the package units to it's "auto-added" list.

## Mantis conversion info:

- **Mantis ID:** 7888
- **OS:** any
- **OS Build:** any
- **Platform:** any
- **Target version:** post 1.0

Story points: 100.0
The spacing of the editor goes mad...


<h3><details><summary>Original Reporter info from Mantis: <small>Joost</small></summary><small>

- **Reporter name:** Joost van der Sluis
</small></details></h3>

## Description:

If I open a file in the lazarus-editor, it looks weird. There are spaces added, all over the place. And if a line is highlighted, it's differently spaced.

Hard to explain, but look at the screenshots. Both editors (gedit and lazarus) shows the same source-file.

## Mantis conversion info:

- **Mantis ID:** 7588
- **Version:** 0.9.19 (SVN)

Story points: 100.0
Properties not stored / restored.


<h3><details><summary>Original Reporter info from Mantis: <small>Matthijs</small></summary><small>

- **Reporter name:** Matthijs Willemstein
</small></details></h3>

## Description:

Properties of a component are set to 0. Whether this happens during saving or reading I do not know.

## Steps to reproduce:

Install latest lazarus snapshot.<br/>
Create a new application.<br/>
Place a component on the form (button / memo)<br/>
Run application.<br/>
No components visible.<br/>
Close application.<br/>
Close Lazarus<br/>
Restart lazarus<br/>
Reopen project.<br/>
Properties like top, left, height, width are set to 0.

## Mantis conversion info:

- **Mantis ID:** 7212
- **OS:** Win32 / Linux
- **OS Build:** XP / FC4
- **Platform:** Intel / AMD
- **Version:** 0.9.17 (SVN)
- **Monitored by:** » crossbuilder (Burkhard Carstens)
- **Target version:** post 1.0

Story points: 100.0
cannot select combox values


<h3><details><summary>Original Reporter info from Mantis: <small>darius</small></summary><small>

- **Reporter name:** Darius Blaszijk
</small></details></h3>

## Description:

when selecting a value from a combobox in the IDE the contents of the combobox remains empty.

## Mantis conversion info:

- **Mantis ID:** 7124
- **OS:** winxp
- **OS Build:** xp
- **Build:** 9572
- **Platform:** i686
- **Version:** 0.9.17 (SVN)
- **Fixed in version:** 0.9.17 (SVN)
- **Fixed in revision:** 9574 (#41947d6c28b0016c92f5b6d05807c94d9f9197ca)
- **Target version:** 0.9.18

Story points: 200.0
Lazarus freezes on new item


<h3><details><summary>Original Reporter info from Mantis: <small>darius</small></summary><small>

- **Reporter name:** Darius Blaszijk
</small></details></h3>

## Description:

Selecting File->New->whatever (unit / form / new ...)  makes Lazarus freeze and the CPU load goes to 100%. 

## Steps to reproduce:

Select file->new (whatever)

## Additional information:

I have tried to make a trace but without success. Lazarus does not cash but goes to 100% CPU.<br/>
Perhaps some information how to pinpoint the problem better would be helpful.

## Mantis conversion info:

- **Mantis ID:** 1782
- **OS:** winxp
- **Platform:** i386
- **Version:** 0.9.13 (SVN)
- **Fixed in version:** 0.9.13 (SVN)
- **Fixed in revision:** 8334 (#6a7d9c6f455a0e5dc33553ec6ac2d6579640080e)
- **Target version:** 0.9.14

Story points: 200.0
Problem with setting breakpoints in the source code editor


<h3><details><summary>Original Reporter info from Mantis: <small>marcgeldon</small></summary><small>

- **Reporter name:** Marc Geldon
</small></details></h3>

## Description:

you can set/unset breakpoints with both mousekeys (left and right). Setting and unsetting should only work with the LEFT mousekey. Because if I click the RIGHT mousekey, I want to call the popup menu. Please fix this.

## Additional information:

In Delphi you can only set breakpoints with LEFT mousekey.

## Mantis conversion info:

- **Mantis ID:** 1313
- **OS:** Windows XP SP2
- **OS Build:** 5.1
- **Platform:** Intel
- **Fixed in version:** 0.9.11 (SVN)
- **Fixed in revision:** 7981 (#4a42afcb2ff6b5bc63b508841822c87e77f8c99a)
- **Target version:** 1.0.0
- **LazTarget:** 1.0

Story points: 100.0
Problem with popup menu in source code editor


<h3><details><summary>Original Reporter info from Mantis: <small>marcgeldon</small></summary><small>

- **Reporter name:** Marc Geldon
</small></details></h3>

## Description:

sometimes the error message "List index (25) out of bounds.".

## Steps to reproduce:

I could not really find a way to reproduce it. But if you set and unset bookmarks often enought. Left click and right click on the gray area in the source code editor where the bookmark numbers and breakpoints are shown, the error will occur for sure after one minute or so (doing this set/unset/left-click/right-click thing).

## Mantis conversion info:

- **Mantis ID:** 1312
- **OS:** Windows XP SP2
- **OS Build:** 5.1
- **Build:** 09.10.2005
- **Platform:** Intel
- **Version:** 0.9.11 (SVN)
- **Target version:** 1.0.0
- **LazTarget:** 1.0

Story points: 100.0
Source editor eats first typed character


<h3><details><summary>Original Reporter info from Mantis: <small>Jesus @jramx</small></summary><small>

- **Reporter name:** Jesus Reyes
</small></details></h3>

## Description:

The source editor sometimes eats the first character typed<br/>
after some operations.

I think it's a known problem, but I found a way to reproduce it.

the problem doesn't occur if one uses the 

## Steps to reproduce:

1. Drop a TEdit in form editor<br/>
2. Double click the TEdit. Source editor is bring to front an is ready to accept source code<br/>
3. type anything, The first

the same happens when doubleclicking the Event in object inspector, it doesn't happen however when clicking the '...' button to add or edit the event in the object inspector.

## Additional information:

Still to test in linux

## Mantis conversion info:

- **Mantis ID:** 1227
- **OS:** Windows
- **OS Build:** 98
- **Build:** 0.9.9 24-SEP-2005
- **Platform:** i386
- **Version:** 0.9.9 (SVN)
- **Fixed in version:** 0.9.11 (SVN)
- **Fixed in revision:** 8004 (#88a48665d5c6a00a704c9e9b2ba62799a280642e)
- **Target version:** 0.9.12

Story points: 100.0
Doesn't use native look for buttons in MessageDlg


<h3><details><summary>Original Reporter info from Mantis: <small>Phil Hess</small></summary><small>

- **Reporter name:** Phil Hess
</small></details></h3>

## Description:

The old-style Delphi green check and red X button glyphs in MessageDlg buttons look bad when the rest of the app's forms use normal looking buttons for OK and Cancel.

Note that this applies to GTK too - looks particularly bad on Mac!


## Mantis conversion info:

- **Mantis ID:** 1062
- **OS:** Windows
- **OS Build:** XP, SP2
- **Build:** 20050722
- **Platform:** Win32
- **Version:** 0.9.9 (SVN)
- **Fixed in version:** 0.9.27 (SVN)
- **Monitored by:** » marcgeldon (Marc Geldon), » luizamerico (Luiz Americo), » emaijala (Ere Maijala)
- **Target version:** 1.4

Story points: 100.0
AutoComplete (Ctrl-Space) problems


<h3><details><summary>Original Reporter info from Mantis: <small>>8<</small></summary><small>

- **Reporter name:** Bug Import
</small></details></h3>

## Description:

Invoking Autocomplete (Ctrl-Space) a unrequest Space_Char is added in the Line editor<br/>
So if you type<br/>
'Showme'<br/>
and then invoke Ctrl-Space, the caret is shifted one place right. Accepting the autocomplete this is the result:<br/>
'Showme ShowMessage();'<br/>
recent Lazarus CVS 

## Additional information:

Imported information<br/>
\--------------------<br/>
Name: Salvatore Coppola<br/>
Mail: coppolastudio (at) virgilio.it

## Mantis conversion info:

- **Mantis ID:** 830
- **Fixed in version:** 0.9.7 (CVS)

Story points: 100.0
C calling convention broken when passing structures larger than two integers.


<h3><details><summary>Original Reporter info from Mantis: <small>Flawless</small></summary><small>

- **Reporter name:** Christian Iversen
</small></details></h3>

## Description:

If a structure is passed by value rather than reference, and is larger than 2 integers, and the calling convention is cdecl, the call will fail.

On page 13 and 16 in this pdf file:

http://www.agner.org/optimize/calling_conventions.pdf

it's quite clearly shown that objects larger than two registers should always be passed on the stack for cdecl (at least on linux, I think the rules are different for windows).

fpc currently tries to pass all 5 arguments in the example program in registers, which causes it to fail. 

## Steps to reproduce:

compile gcc program with: gcc -masm=intel -fverbose-asm -save-temps -c test.c<br/>
compile fpc program with: fpc -al testp.pas

testp.pas:
``` pascal
program testp;

uses
  ctypes, vorbis;

{$LINKLIB 'c'}
{$LINK 'test'}

function ov_open_callbacks_foo(datasource: pointer; var vf: OggVorbis_File; initial: pointer; ibytes: clong; callbacks: ov_callbacks): cint; cdecl; external;

var
  vf: OggVorbis_File;
  cb: ov_callbacks;
begin
  cb.read := read_func(pointer(10));
  cb.seek := seek_func(pointer(20));
  cb.close := close_func(pointer(30));
  cb.tell := tell_func(pointer(40));
  ov_open_callbacks_foo(pointer(1), vf, pointer(3), 4, cb);
end.
```


\#include &LtPos;stdio.h><br/>
\#include &LtPos;vorbis/vorbisfile.h>

int ov_open_callbacks_foo(void *datasource, OggVorbis_File *vf, char *initial, long ibytes, ov_callbacks callbacks) {<br/>
```  printf("%p:%p:%p:%d:%p\n", datasource, vf, initial, ibytes, callbacks);```<br/>
}

## Mantis conversion info:

- **Mantis ID:** 7453
- **OS:** Linux
- **OS Build:** 2.6.15
- **Build:** [2006/09/21] for x86_64
- **Platform:** Amd64
- **Version:** 2.2.0
- **Fixed in version:** 2.2.0
- **Fixed in revision:** 4688 (#360cbe1de1d45d93d439b067ed9e7f9f43515194)

Story points: 100.0
pthread_cond_timedwait is called with wrong timespec


<h3><details><summary>Original Reporter info from Mantis: <small>crossbuilder</small></summary><small>

- **Reporter name:** Burkhard Carstens
</small></details></h3>

## Description:

In rtl/unix/cthreads.pp line 552 ff, timespec is created from the value of timeout. According to "man pthread_cond_wait" and my tests, it should be now+timeout. iow, this is meant to specify the absolute time, when the timeout should ocour rather than a relative timeout. <br/>
The way it is now, this allwas gives a time in the past, therefore this call allways returns immediately.


## Mantis conversion info:

- **Mantis ID:** 7196
- **OS:** linux
- **OS Build:** suse 10.0
- **Build:** 4277
- **Platform:** i386
- **Version:** 2.2.0

Story points: 300.0
Incorrect fillchar call

I have found 4 instances where fillchar is called with incorrect parameters:

```
compiler\fmodule.pas (338,9) Fillchar(current_filepos,0,sizeof(current_filepos));
packages\rtl-console\src\win\video.pp (778,3) FillChar (VioMode, 0, SizeOf (VioMode));
packages\winceunits\src\windbase.pp (534,3) fillchar(pguid,0,sizeof(CEGUID));
rtl\os2\systhrd.inc (253,2) FillChar (DataIndex^^, 0, ThreadVarBlockSize);
```

These may not be causing any direct harm but they could cause random problems that will be hard to diagnose so they should be fixed.

Story points: 100.0
Optimizer leads to wrong short boolean code generation


<h3><details><summary>Original Reporter info from Mantis: <small>Pierre @PierreMuller</small></summary><small>

- **Reporter name:** Pierre Muller
</small></details></h3>

## Description:

```  Reported by Tobias Giesen on fpc-pascal mailinglist, 2021/05/30```<br/>

Hello,<br/>
it seems that the newest 32-bit FPC sometimes creates complete Boolean Evaluation<br/>
rather than partial, which causes my application to crash. My context is like this:

``` pascal
type BOOL=LongBool;
         PBOOL=^LongBool;

function DoSomething(const Cancel:PBOOL=nil);
begin
   if Assigned(Cancel) and Cancel^ then
      Exit;
   end;
```

This crashes because Cancel and Cancel^ are always evaluated, even if Cancel is nil.

It works fine in 64-bit.

Is this a known problem?

Cheers,<br/>
Tobias

I modified this to a simple test, which shows that x86_64 3.2.2 release compiler<br/>
also generates wrong code for this simple source!

## Steps to reproduce:

muller@gcc10:~/pas/check$ fpc -gl -O2 test-complete-boolean.pp  -al<br/>
Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64<br/>
Copyright (c) 1993-2021 by Florian Klaempfl and others<br/>
Note: Switching assembler to default source writing assembler<br/>
Target OS: Linux for x86-64<br/>
Compiling test-complete-boolean.pp<br/>
Assembling program<br/>
Linking test-complete-boolean<br/>
26 lines compiled, 0.2 sec<br/>
1 note(s) issued<br/>
muller@gcc10:~/pas/check$ ./test-complete-boolean<br/>
First try<br/>
2nd try<br/>
Runtime error 216 at $00000000004001E2<br/>
```   $00000000004001E2  DOSOMETHING,  line 8 of test-complete-boolean.pp```<br/>

## Additional information:

muller@gcc10:~/pas/check$ cat  test-complete-boolean.pp<br/>
{$mode objfpc}

type BOOL=LongBool;<br/>
```      PBOOL=^LongBool;```<br/>

``` pascal
procedure DoSomething(const Cancel:PBOOL=nil);
begin
  if Assigned(Cancel) and Cancel^ then
    Exit;
  writeln('Cancel is false');
end;

var
    b : BOOL;
    pb : PBOOL;
begin
   b:=true;
   pb:=@b;
   Writeln('First try');
   DoSomething(pb);
   pb:=nil;
   Writeln('2nd try');
   DoSomething(pb);
   Writeln('3rd try');
   DoSomething;
end.
```

## Mantis conversion info:

- **Mantis ID:** 38973
- **OS:** At least MacOS and Linux
- **Version:** 3.2.2

Story points: 100.0
Crash in TWriter with read only class property = nil


<h3><details><summary>Original Reporter info from Mantis: <small>Martin @martin_frb</small></summary><small>

- **Reporter name:** Martin Friebe
</small></details></h3>

## Description:

Trying to write a component with a readonly class property that is nil will crash in WriteProperty


```
#0 CLASSES$_$TWRITER_$__$$_WRITEPROPERTY$TPERSISTENT$POINTER+275 at :0
#1 CLASSES$_$TWRITER_$__$$_WRITEPROPERTIES$TPERSISTENT+116 at :0
#2 CLASSES$_$TWRITER_$__$$_WRITECOMPONENTDATA$TCOMPONENT+151 at :0
#3 CLASSES$_$TWRITER_$__$$_WRITEDESCENDENT$TCOMPONENT$TCOMPONENT+51 at :0
#4 SYSTEM_$$_MAIN_WRAPPER$POINTER$POINTER$$INT64+6 at :0
```


``` pascal
procedure TWriter.WriteProperty(Instance: TPersistent; PropInfo: Pointer);
....
  PropType := PPropInfo(PropInfo)^.PropType;
  if not Assigned(PPropInfo(PropInfo)^.SetProc) then begin
    if PropType^.Kind<>tkClass then
      exit;
    ObjValue := TObject(GetObjectProp(Instance, PropInfo));
    if not ObjValue.InheritsFrom(TComponent) or
       not (csSubComponent in TComponent(ObjValue).ComponentStyle) then
      exit;
  end;
```


ObjValue will be nil.

The code should have "not assigned(ObjValue) or" added:

```
    if not assigned(ObjValue) or
       not ObjValue.InheritsFrom(TComponent) or
       not (csSubComponent in TComponent(ObjValue).ComponentStyle) then
      exit;
```

## Steps to reproduce:

``` pascal
program Project1;
{$mode objfpc}{$H+}
uses
  Classes;

type

  TMyComponent = class(TComponent)
  private
    FFoo: TComponent;
  published
    property ReadOnly: TComponent read FFoo;  // will be nil
  end;

var
  strm: TMemoryStream;
  Driver: TAbstractObjectWriter;
  Writer: TWriter;
  Reader: TReader;
  o: TMyComponent;
begin
  o := TMyComponent.Create(nil);

  strm := TMemoryStream.Create;
  Driver := TBinaryObjectWriter.Create(strm,4096);
  Writer := TWriter.Create(Driver);
  Writer.WriteRootComponent(o);
  Driver.Free;
  Writer.Free;

  strm.Free;
end.
```

## Mantis conversion info:

- **Mantis ID:** 38920
- **OS:** win 10
- **OS Build:** 10
- **Platform:** 64bit Intel
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 49389 (#61cd38e6db176dd006be6adb8c6c350011a8b108)
- **Target version:** 4.0.0

Story points: 100.0
[Patch] AArch64 incorrect number generation fix


<h3><details><summary>Original Reporter info from Mantis: <small>CuriousKit @CuriousKit</small></summary><small>

- **Reporter name:** J. Gareth Moreton
</small></details></h3>

## Description:

This patch fixes a bug in AArch64's a_load_const_reg routine where certain constants were not encoded properly.  This, ironically, manifested in a_load_const_reg itself and caused inefficient (but correct) code generation for other numbers.

## Steps to reproduce:

Apply patch and confirm both correct code compilation and more efficient constant generation in the system unit's disassembly (among other things).

## Additional information:

In the aforementioned a_load_const_reg routine, the constant $0000FFFFFFFEFFFF was instead generated as $FFFEFFFFFFFEFFFF, causing a case block to not be evaluated correctly.  The class of numbers that were incorrectly encoded are those where replacing the upper 16 bits with the 2nd lowest 16 bits produced a valid shifter constant, since this could be encoded compactly as (using $0000FFFFFFFEFFFF as an example):

```
	orr  x0,xzr,0xFFFEFFFFFFFEFFFF
	movk x0,0,lsl 48
```

Previously, the "movk" instruction was erroneously omitted if the upper 16 bits were zero.

\----

For an inefficient code example, the System unit had many such constants - for the number 18.874,385 ($01200011):

```
	movn	x1,65518
	movk	x1,288,lsl 16
	movk	x1,0,lsl 32
	movk	x1,0,lsl 48
```

This patch now allows the routine to properly encode the constant as expected:

```
	movz	x1,17
	movk	x1,288,lsl 16
```

## Mantis conversion info:

- **Mantis ID:** 38695
- **OS:** LInux (Raspberry Pi OS)
- **OS Build:** 5.4.51-v8+
- **Build:** r49099
- **Platform:** aarch64-linux
- **Version:** 3.3.1
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 49104 (#f0023a3b04a3873759c66b7053bb053f2b771775)

Story points: 100.0
Wrong code generated on x86-64


<h3><details><summary>Original Reporter info from Mantis: <small>runewalsh</small></summary><small>

- **Reporter name:** 
</small></details></h3>

## Description:

Code below should write "#######... 70%", but depending on compiler settings it writes garbage or even crashes.<br/>
I have this happening on x86-64-win64 with optimization levels greater than -O1.

Bug vanishes after replacing<br/>
pChar(result)[i] :=<br/>
with conventional<br/>
result[1 + i] :=

or after removing the second condition part, i. e.<br/>
(i = int32(divs) - 1) and (progress >= 1)

or after replacing any of 32-bit variables with 64-bit equivalent

so I can't even come close to guessing what's going on here.

## Steps to reproduce:

``` pascal
function Bar(const progress: single; divs: uint32): string;
const
	BarSym: array[boolean] of char = ('.', '#');
var
	i: int32;
begin
	SetLength(result, divs);
	for i := 0 to int32(divs) - 1 do
		pChar(result)[i] := BarSym[(progress >= (0.75 + i) / divs) or (i = int32(divs) - 1) and (progress >= 1)];
end;

var
	s: string;

begin
	writeln(Bar(0.7, 10) + ' 70%');
end.
```

## Mantis conversion info:

- **Mantis ID:** 38129
- **Build:** 63950
- **Platform:** x86-64-win64
- **Fixed in version:** 3.3.1
- **Fixed in revision:** 49095 (#cc64d9eb4e036d8185c75393c21968cdbbb73e87)
- **Monitored by:** » Vincent (Vincent Snijders), » @MageSlayer (Denis Golovan), » @CuriousKit (J. Gareth Moreton)

Story points: 200.0