Difference between revisions of "User Changes Trunk"

From Free Pascal wiki
Jump to navigationJump to search
m (Fix typos)
 
(93 intermediate revisions by 14 users not shown)
Line 1: Line 1:
 
== About this page==
 
== About this page==
  
Listed below are intentional changes made to the FPC compiler (trunk) since the [[User_Changes_3.0|previous release]] that may break existing code. The list includes reasons why these changes have been implemented, and suggestions for how you might adapt your code if you find that previously working code has been adversely affected by these recent changes.  
+
Listed below are intentional changes made to the FPC compiler (trunk) since the [[User_Changes_3.2.2|previous release]] that may break existing code. The list includes reasons why these changes have been implemented, and suggestions for how you might adapt your code if you find that previously working code has been adversely affected by these recent changes.  
  
 
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].
 
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].
Line 8: Line 8:
  
 
== All systems ==
 
== All systems ==
 +
 +
=== Language Changes ===
 +
 +
==== Precedence of the IS operator changed ====
 +
* '''Old behaviour''': The IS operator had the same precedence as the multiplication, division etc. operators.
 +
* '''New behaviour''': The IS operator has the same precedence as the comparison operators.
 +
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].
 +
* '''Remedy''': Add parenthesis where needed.
 +
 +
==== Visibilities of members of generic specializations ====
 +
* '''Old behaviour''': When a generic is specialized then visibility checks are handled as if the generic was declared in the current unit.
 +
* '''New behaviour''': When a generic is specialized then visibility checks are handled according to where the generic is declared.
 +
* '''Reason''': Delphi-compatibility, but also a bug in how visibilities are supposed to work.
 +
* '''Remedy''': Rework your code to adhere to the new restrictions.
  
 
=== Implementation Changes ===
 
=== Implementation Changes ===
  
==== Dynamic array parameters are passed like pointers ====
+
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====
* '''Old behaviour''': When using the default calling convention, dynamic array parameters were passed on the stack.
+
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.
* '''New behaviour''': When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).
+
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.
* '''Reason''': Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.
+
* '''Reason''': When passing a dynamic array by value, modifications to its contents by the callee are also visible on the caller side. However, if an array is implicitly converted to a dynamic array, the result is a temporary value and hence changes are lost. This issue came up when adding [https://bugs.freepascal.org/view.php?id=35580 TStream.Read() overloads].
* '''Remedy''': Adjust pure assembler routines that have dynamic array parameters.
+
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}''
* '''svn''': 30870, 30878, 31622
+
* '''Example''': this program demonstrates the issue that appeared with the TStream.Read() overloads that were added (originally, only the the version with the untyped variable existed)
 +
 
 +
<syntaxhighlight lang="pascal">
 +
{$mode objfpc}
 +
type
 +
  tdynarray = array of byte;
  
==== VMT Interface table uses private variable FPC_EMPTYINTF ====
+
procedure test(var arr); overload;
* '''Old behaviour''': The vIntfTable field has three possible values:
+
begin
**Nil if the class doesn't implement any interface (but an ancestor might)
+
  pbyte(arr)[0]:=1;
**A pointer to an interface table (with count <> 0) if the class implements any interface
+
end;
**A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface
 
* '''New behaviour''': The vIntfTable field has two possible values:
 
**Nil if neither the class nor any ancestor implements an interface
 
**A pointer to an interface table in any other case
 
* '''Reason''': FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems
 
* '''Remedy''': Adjust code accordingly
 
* '''svn''': 34087
 
  
==== Modeswitch ''TypeHelpers'' in Delphi modes enables ''type helper''-syntax ====
+
procedure test(arr: tdynarray); overload;
* '''Old behaviour''': The modeswitch ''TypeHelpers'' is enabled by default in Delphi modes and allows to extend primitive types with ''record helper'' types.
+
begin
* '''New behaviour''':
+
  test[0]:=1;
**The modeswitch is no longer set by default.
+
end;
**Primitive types can always be extended by record helpers in Delphi modes.
 
**The modeswitch enables the ''type helper''-syntax as known from non-Delphi modes.
 
* '''Reason''': The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.
 
* '''Remedy''': The only problems arise if one disabled the modeswitch on purpose which now longer disallows the extension of primitive types.
 
* '''svn''': 37225
 
  
==== Class references in a class VMT's field table ====
+
var
* '''Old behaviour''': The class array of the vFieldTable of the VMT contains an array of TClass entries
+
  regulararray: array[1..1] of byte;
* '''New behaviour''': The class array of the vFieldTable of the VMT contains an array of PClass entries
+
begin
* '''Reason''': As for the RTTI the indirect references are necessary for dynamic packages.
+
  regulararray[1]:=0;
* '''Remedy''': Use an additional dereferentiation to access the class type.
+
  test(arr);
* '''svn''': 37485
+
  writeln(arr[0]); // writes 0, because it calls test(tdynarr)
 +
end.
 +
</syntaxhighlight>
 +
* '''svn''': 42118
  
=== Language Changes ===
+
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====
 +
* '''Old behaviour''': A function/procedure/method or procedure/method variable type could be followed by a directive clause in square brackets (''[…]'') that contains the directives for the routine or type (e.g. calling convention).
 +
* '''New behaviour''': If the modeswitch ''PrefixedAttributes'' is enabled (which is the default in modes ''Delphi'' and ''DelphiUnicode'') the directive clause in square brackets is no longer allowed.
 +
* '''Reason''': As custom attributes are bound to a type/property in a way that looks ambiguous to a directive clause and this ambiguity is not easily solved in the parser it is better to disable this feature.
 +
* '''Remedy''':
 +
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')
 +
** rework your directive clause:
 +
<syntaxhighlight lang="pascal">
 +
// this
 +
procedure Test; cdecl; [public,alias:'foo']
 +
begin
 +
end;
  
==== Visibility of generic type parameters ====
+
// becomes this
* '''Old behaviour''': Type parameters of generics had ''public'' visibility.
+
procedure Test; cdecl; public; alias:'foo';
* '''New behaviour''': Type parameters of generics now have ''strict private'' visibility.
+
begin
* '''Reason''': With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [http://bugs.freepascal.org/view.php?id=25917 this] bug report). Also the fix is Delphi compatible.
+
end;
* '''Remedy''': Declare a type alias for the type parameter with the desired visibility.
 
* '''Example''': In the following example ''T'' is declared as ''strict private'', while ''TAlias'' is declared as ''public'' and thus can be used as before the change.
 
<syntaxhighlight>
 
type
 
  generic TTest<T> = class
 
  public type
 
    TAlias = T;
 
  end;
 
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
* '''svn''': 42402
 +
 +
==== Type information contains reference to attribute table ====
 +
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.
 +
* '''New behavior''': The first field of the data represented by ''TTypeData'' is a reference to the custom attributes that are attributed to the type, only then the type specific fields follow.
 +
* '''Reason''': Any type can have attributes, so it make sense to provide this is a common location instead of having to parse the different types.
 +
* '''Remedy''':
 +
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).
 +
** If you directly access the binary data you need handle an additional ''Pointer'' field at the beginning of the ''TTypeData'' area and possibly correct the alignment for platforms that have strict alignment requirements (e.g. ARM or M68k).
 +
* '''svn''': 42375
 +
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====
 +
* '''Old behavior''': The compiler accepted every integer value as explicit enumeration value. The value was silently reduced to the longint range if it fell outside of that range
 +
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.
 +
* '''Reason''': ''Type TEnum = (a = $ffffffff);'' resulted in an enum with size 1 instead of 4 as would be expected, because  $ffffffff was interpreted as "-1".
 +
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.
 +
 +
==== Comp as a type rename of Int64 instead of an alias ====
 +
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').
 +
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').
 +
* '''Reason''':
 +
** This allows overloads of ''Comp'' and ''Int64'' methods/functions
 +
** This allows to better detect properties of type ''Comp''
 +
** Compatibility with Delphi for Win64 which applied the same reasoning
 +
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.
 +
* '''svn''': 43775
  
==== Parsing of ''specialize'' has been changed ====
+
==== Routines that only differ in result type ====
* '''Old behaviour''': ''specialize'' was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.
+
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.
* '''New behaviour''': ''specialize'' is now considered part of the specialized type, just as ''generic'' is. This means that unit names and parent types need to be used before the part containing the ''specialize''.
+
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.
* '''Reason''': This allows for a more logical usage of ''specialize'' in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.
+
* '''Reason:''' It makes no sense to allow this as there are situations where the compiler will not be able to determine which function to call (e.g. a simple call to a function ''Foo'' without using the result).
* '''Remedy''': Put the ''specialize'' directly in front of the type which needs to be specialized.
+
* '''Remedy:''' Correctly declare overloads.
 +
* '''Notes:'''
 +
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.
 +
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.
 +
* '''svn:''' 45973
  
=== RTTI changes ===
+
==== Open Strings mode enabled by default in mode Delphi ====
 +
* '''Old behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') was not enabled in mode Delphi.
 +
* '''New behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') is enabled in mode Delphi.
 +
* '''Reason:''' Delphi compatibility.
 +
* '''Remedy:''' If you have assembly routines with a ''var'' parameter of type ''ShortString'' then you also need to handle the hidden ''High'' parameter that is added for the Open String or you need to disable Open Strings for that routine.
 +
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/188cac3bc6dc666167aacf47fedff1a81d378137 188cac3b]
  
==== RTTI for Interfaces (published property count) ====
+
=== Unit changes ===
* '''Old behavior''': The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count.
 
* '''New behavior''': Before the property RTTI data is now a Word count field that specifies the amount of properties
 
* '''Reason''': Both user request and usability.
 
* '''Remedy''': Adjust pointer offsets accessing the property data accordingly.
 
  
==== RTTI for COM Interfaces (IID String) ====
+
==== System - TVariantManager ====
* '''Old behavior''': COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.
 
* '''New behavior''': The undocumented field has been removed.
 
* '''Reason''': The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.
 
* '''Remedy''': Use the GUID field and convert that to a String.
 
  
==== RTTI Binary format change ====
+
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.
* '''Old behavior''': References to other types are designated by PTypeInfo.
+
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.
* '''New behavior''': References to other types are designated by PPTypeInfo.
+
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.
* '''Reason''': While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.
+
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.
* '''Remedy''': If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.
+
* '''svn:''' 41570
* '''Note''':
 
**The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.
 
**This does not apply to TObject.ClassInfo which still returns a PTypeInfo
 
  
==== RTTI for Corba Interfaces (IID String) ====
+
==== System - buffering of output to text files ====
* '''Old behavior''': IIDStr is a field of TTypeData.
 
* '''New behavior''': IIDStr is a property of TTypeData.
 
* '''Reason''': The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.
 
* '''Remedy''': If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.
 
* '''svn''': 35026
 
  
==== Reference to Record Init Information ====
+
* '''Old behaviour:''' Buffering was disabled only for output to text files associated with character devices (Linux, BSD targets, OS/2), or for output to Input, Output and StdErr regardless of their possible redirection (Win32/Win64, AIX, Haiku, BeOS, Solaris).
* '''Old behavior''': Field RecSize follows directly after start of TTypeData record.
+
* '''New behaviour:''' Buffering is disabled for output to text files associated with character devices, pipes and sockets (the latter only if the particular target supports accessing sockets as files - Unix targets).
* '''New behavior''': Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).
+
* '''Reason for change:''' The same behaviour should be ensured on all supported targets whenever possible. Output to pipes and sockets should be performed immediately, equally to output to character devices (typically console) - in case of console users may be waiting for the output, in case of pipes and sockets some other program is waiting for this output and buffering is not appropriate. Seeking is not attempted in SeekEof implementation for files associated with character devices, pipes and sockets, because these files are usually not seekable anyway (instead, reading is performed until the end of the input stream is reached).
* '''Reason''': With the record init information one can more quickly decide whehther a record needs to be classed as ''managed'' or not which is among others useful for the IsManaged() function of the Rtti unit.
+
* '''Remedy:''' Buffering of a particular file may be controlled programmatically / changed from the default behaviour if necessary. In particular, perform TextRec(YourTextFile).FlushFunc:=nil immediately after opening the text file (i.e. after calling Rewrite or after starting the program in case of Input, Output and StdErr) and before performing any output to this text to enable buffering using the default buffer, or TextRec(YourTextFile).FlushFunc:=TextRec(YourTextFile).FileWriteFunc to disable buffering.
* '''Remedy''': If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.
+
* '''svn:''' 46863
* '''Note''': The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.
 
* '''svn''': 35125, 35134
 
  
==== TOrdType extended ====
+
==== System - type returned by BasicEventCreate on Windows ====
* '''Old behavior''': TOrdType contains entries for 8-, 16- and 32-bit widths.
 
* '''New behavior''': TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.
 
* '''Reason''': Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.
 
* '''Remedy''': Adjust arrays that have TOrdType as index.
 
* '''svn''': 35135
 
  
==== New OrdType field for tkInt64 and tkQWord ====
+
* '''Old behaviour:''' BasicEventCreate returns a pointer to a record which contains the Windows Event handle as well as the last error code after a failed wait. This record was however only provided in the implementation section of the  ''System'' unit.
* '''Old behavior''': MinInt64Value and MinQWordValue follow directly after start of TTypeData record.
+
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.
* '''New behavior''': MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.
+
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.
* '''Reason''': To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.
+
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.
* '''Remedy''': If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.
+
* '''svn:''' 49068
* '''svn''': 35135
 
  
==== First field of TProcedureParam changed ====
+
==== System - Ref. count of strings ====
* '''Old behavior''': First field of TProcedureParam is called Flags and has type Byte.
 
* '''New behavior''': First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.
 
* '''Reason''': Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.
 
* '''Remedy''': Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.
 
* '''svn''': 35174
 
  
==== TParamFlag extended for constref ====
+
* '''Old behaviour:''' Reference counter of strings was a ''SizeInt''
* '''Old behavior''': TParamFlag has no entry for constref parameters.
+
* '''New behaviour:'''  Reference counter of strings is now a ''Longint'' on 64 Bit platforms and ''SizeInt'' on all other platforms.
* '''New behavior''': TParamFlag has entry pfConstRef for constref parameters.
+
* '''Reason for change:''' Better alignment of strings
* '''Reason''': To correctly detect constref parameters they need to be marked accordingly.
+
* '''Remedy:''' Call ''System.StringRefCount'' instead of trying to access the ref. count field by pointer operations or other tricks.
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).
+
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e ee10850a57]
* '''svn''': 35175
 
  
==== Ranges of Boolean types adjusted ====
+
==== System.UITypes - function TRectF.Union changed to procedure ====
* '''Old behavior''': ByteBool, WordBool and LongBool have a range of 0..-1.
 
* '''New behavior''': ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).
 
* '''Reason''': The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.
 
* '''Remedy''': Adjust code that might have relied on the range being ''invalid''.
 
* '''svn''': 35184
 
  
==== OrdType of Boolean64 and QWordBool adjusted ====
+
* '''Old behaviour:''' ''function TRectF.Union(const r: TRectF): TRectF;''
* '''Old behavior''': Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.
+
* '''New behaviour:''' ''procedure TRectF.Union(const r: TRectF);''
* '''New behavior''': Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.
+
* '''Reason for change:''' Delphi compatibility and also compatibility with TRect.Union
* '''Reason''': Both types have a size of 64-bit thus using a smaller size is incorrect.
+
* '''Remedy:''' Call ''class function TRectF.Union'' instead.
* '''Remedy''': Use the correct fields to retrieve the range boundaries of the types.
+
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/5109f0ba444c85d2577023ce5fbdc2ddffc267c8 5109f0ba]
* '''svn''': 35185
 
  
==== All Boolean types have TypeKind tkBool ====
+
==== 64-bit values in OleVariant ====
* '''Old behavior''': Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.
 
* '''New behavior''': Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.
 
* '''Reason''': Consistency and possibility to differentiate ordinary subranges from the real Boolean types.
 
* '''Remedy''': Check for TypeKind tkBool instead of some "magic" to detect Boolean types.
 
* '''Note''': Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.
 
* '''svn''': 35186, 35187
 
  
==== TParamFlag extended for hidden parameters ====
+
* '''Old behaviour:''' If a 64-bit value (''Int64'', ''QWord'') is assigned to an OleVariant its type is ''varInteger'' and only the lower 32-bit are available.
* '''Old behavior''': TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1
+
* '''New behaviour:''' If a 64-bit value (''Int64'', ''QWord'') is assigned to an OleVariant its type is either ''varInt64'' or ''varQWord'' depending on the input type.
* '''New behavior''': TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2
+
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.
* '''Reason''': As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.
+
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).
+
* '''svn:''' 41571
* '''svn''': 35267, 35286, 35291
 
  
=== Unit changes ===
+
==== Classes TCollection.Move ====
 +
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.
 +
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.
 +
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.
 +
* '''Remedy:'''  prepend the Move() call with the system unit name: System.move().
 +
* '''svn:''' 41795
 +
 
 +
==== Math Min/MaxSingle/Double ====
 +
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.
 +
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.
 +
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://gitlab.com/freepascal.org/fpc/source/-/issues/36870.
 +
* '''Remedy:'''  If the code really depends on the old values, rename them and use them as renamed.
 +
* '''svn:''' 44714
  
==== SysUtils ====
+
==== Random generator ====
* '''Old behaviour:''' faSymlink had the numerical value $40. This was wrong on windows, and not compatible with Delphi.
+
* '''Old behaviour:''' FPC uses a Mersenne twister generate random numbers
* '''New behaviour:''' faSymlink has the numerical value $400. Correct on windows.
+
* '''New behaviour:''' Now it uses Xoshiro128**
* '''Reason for change:''' Wrong functionality and Delphi compatibility.
+
* '''Reason for change:''' Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.
* '''Remedy:''' If you are using the old numerical constant $40, simply use faSymlink instead.
+
* '''Remedy:''' When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.
 +
* '''git:''' 91cf1774
  
===== TList auto-growth =====
+
==== Types.TPointF.operator * ====
* '''Old behaviour:''' Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity
+
* '''Old behaviour:''' for <code>a, b: TPointF</code>, <code>a * b</code> is a synonym for <code>a.DotProduct(b)</code>: it returns a <code>single</code>, scalar product of two input vectors.
* '''New behaviour:''' Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.
+
* '''New behaviour:''' <code>a * b</code> does a component-wise multiplication and returns <code>TPointF</code>.
* '''Reason for change:''' Avoid out-of-memory when very large lists are expanded
+
* '''Reason for change''': Virtually all technologies that have a notion of vectors use <code>*</code> for component-wise multiplication. Delphi with its <code>System.Types</code> is among these technologies.
 +
* '''Remedy:''' Use newly-introduced <code>a ** b</code>, or <code>a.DotProduct(b)</code> if you need Delphi compatibility.
 +
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/f1e391fb415239d926c4f23babe812e67824ef95 f1e391fb]
  
==== Classes ====
+
==== CocoaAll ====
* '''Old behaviour:''' ISTreamAdaptor Interface (classes unit and jwa units) used Int64 for various out parameters.
+
===== CoreImage Framework Linking =====
* '''New behaviour:''' ISTreamAdaptor Interface (classes unit and jwa units) use QWord for various out parameters.
+
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.
* '''Reason for change:''' The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.
+
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.
* '''Remedy:''' If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.
+
* '''Reason for change''': The ''CoreImage'' framework is not available on OS X 10.10 and earlier (it's part of ''QuartzCore'' there, and does not exist at all on some even older versions).
 +
* '''Remedy'''If you use functionality that is only available as part of the separate ''CoreImage'' framework, explicitly link it in your program using the ''{$linkframework CoreImage}'' directive.
 +
* '''svn''': 45767
  
 
==== DB ====
 
==== DB ====
===== TParam.LoadFromFile sets share mode to fmShareDenyWrite =====
+
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====
* '''Old behaviour''': TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file
+
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).
* '''New behaviour''': TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file
+
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).
* '''Remedy''': If your application requires exclusive access to file specify fmShareExclusive
+
* '''Reason for change:''' native support for new data types introduced in MS SQL Server 2008 (like DATE, TIME, DATETIME2). FreeTDS client library version 0.95 or higher required.
 
+
* '''svn''': 42737
===== CodePage aware TStringField and TMemoField =====
 
* '''Old behaviour''': These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.
 
* '''New behaviour''': When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.
 
  
===== ODBC headers on Unix platforms defaults to 3.52 version =====
+
===== DB.TFieldType: new types added =====
* '''Old behaviour''': default was ODBCVER $0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.
+
* '''Old behaviour:''' .
* '''New behaviour''': default is  ODBCVER $0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).
+
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField
 +
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types
 +
* '''svn''': 47217, 47219, 47220, 47221; '''git''': c46b45bf
  
===== TStringStream now observe system encoding =====
+
==== DaemonApp ====
* '''Old behaviour''': TStringStream copied bytes as-is from the string specified in the constructor.  
+
===== TDaemonThread =====
* '''New behaviour''': Now bytes are fetched from the string using the encoding of the string.
+
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.
 +
* '''New behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes three parameters of which the first is the control code, the other two are an additional event type and event data.
 +
* '''Reason for change:''' Allow for additional event data to be passed along which is required for comfortable handling of additional control codes provided on Windows.
 +
* '''svn''': 46327
  
== Linux/Android platforms ==
+
===== TDaemon =====
 +
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.
 +
* '''New behaviour:''' If an event handler is assigned to ''OnControlCodeEvent'' and that sets the ''AHandled'' parameter to ''True'' then ''OnControlCode'' won't be called, otherwise it will be called if assigned.
 +
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.
 +
* '''svn''': 46327
  
=== GNU Binutils 2.19.1 or later are required by default ===
+
==== FileInfo ====
* '''Old behaviour''': The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"
+
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.
* '''New behaviour''': The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.
+
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.
* '''Reason''': Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).
+
* '''Reason for change:''' Breaks up a cycle in build dependencies after introducing a RC file parser into ''fcl-res''. This should only affect users that compile trunk due to stale PPU files in the old location or that use a software distribution that splits the FPC packages (like Debian).
* '''Remedy''': If you have a system with an older version of GNU Binutils, you can use the new ''-X9'' command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.
+
* '''svn''': 46392
  
== i386 platforms ==
+
==== Sha1 ====
 +
* '''Old behaviour:''' Sha1file silently did nothing on file not found.
 +
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.
 +
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.
 +
* '''svn''': 49166
  
=== -Ooasmcse/{$optimization asmcse} has been removed ===
+
==== Image ====
* '''Old behaviour''': The compiler contained an assembler common subexpression elimination pass for the i386 platform.
+
===== FreeType: include bearings and invisible characters into text bounds =====
* '''New behaviour''': This optimisation pass has been removed from the compiler.
+
* '''Old behaviour:''' When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.
* '''Reason''': That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.
+
* '''New behaviour:''' the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.
* '''Remedy''': Don't use -Ooasmcse/{$optimization asmcse} anymore.
+
* '''Reason for change:''' The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.
 +
* '''svn''': 49629
  
== i8086 platforms ==
+
==== Generics.Collections & Generics.Defaults ====
 +
* '''Old behaviour:''' Various methods had '''constref''' parameters.
 +
* '''New behaviour:''' '''constref''' parameters were changed to '''const''' parameters.
 +
* '''Reason for change:'''
 +
** Delphi compatibility
 +
** Better code generation especially for types that are smaller or equal to the ''Pointer'' size.
 +
* '''Remedy:''' Adjust parameters of method pointers or virtual methods.
 +
* '''git''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/693491048bf2c6f9122a0d8b044ad0e55382354d 69349104]
  
=== the codepointer type has been changed in the small and compact memory models ===
+
== AArch64/ARM64 ==
 +
=== ''{''-style comments no longer supported in assembler blocks ===
 +
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal
 +
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.
 +
* '''Reason for change''': Support has been added for register sets in the AArch64 assembler reader (for the ld1/ld2/../st1/st2/... instructions), which also start with ''{''.
 +
* '''Remedy''': Use ''(*'' or ''//'' to start comments
 +
* '''svn''': 47116
  
* '''Old behaviour''': The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.
 
* '''New behaviour''': The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.
 
* '''Reason''': Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.
 
  
 +
== Darwin/iOS ==
  
 
== Previous release notes ==
 
== Previous release notes ==

Latest revision as of 17:32, 9 February 2024

About this page

Listed below are intentional changes made to the FPC compiler (trunk) since the previous release that may break existing code. The list includes reasons why these changes have been implemented, and suggestions for how you might adapt your code if you find that previously working code has been adversely affected by these recent changes.

The list of new features that do not break existing code can be found here.

Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.

All systems

Language Changes

Precedence of the IS operator changed

  • Old behaviour: The IS operator had the same precedence as the multiplication, division etc. operators.
  • New behaviour: The IS operator has the same precedence as the comparison operators.
  • Reason: Bug, see [1].
  • Remedy: Add parenthesis where needed.

Visibilities of members of generic specializations

  • Old behaviour: When a generic is specialized then visibility checks are handled as if the generic was declared in the current unit.
  • New behaviour: When a generic is specialized then visibility checks are handled according to where the generic is declared.
  • Reason: Delphi-compatibility, but also a bug in how visibilities are supposed to work.
  • Remedy: Rework your code to adhere to the new restrictions.

Implementation Changes

Disabled default support for automatic conversions of regular arrays to dynamic arrays

  • Old behaviour: In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.
  • New behaviour: By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.
  • Reason: When passing a dynamic array by value, modifications to its contents by the callee are also visible on the caller side. However, if an array is implicitly converted to a dynamic array, the result is a temporary value and hence changes are lost. This issue came up when adding TStream.Read() overloads.
  • Remedy: Either change the code so it no longer assigns regular arrays to dynamic arrays, or add {$modeswitch arraytodynarray}
  • Example: this program demonstrates the issue that appeared with the TStream.Read() overloads that were added (originally, only the the version with the untyped variable existed)
{$mode objfpc}
type
  tdynarray = array of byte;

procedure test(var arr); overload;
begin
  pbyte(arr)[0]:=1;
end;

procedure test(arr: tdynarray); overload;
begin
  test[0]:=1;
end;

var
  regulararray: array[1..1] of byte;
begin
  regulararray[1]:=0;
  test(arr);
  writeln(arr[0]); // writes 0, because it calls test(tdynarr)
end.
  • svn: 42118

Directive clause […] no longer useable with modeswitch PrefixedAttributes

  • Old behaviour: A function/procedure/method or procedure/method variable type could be followed by a directive clause in square brackets ([…]) that contains the directives for the routine or type (e.g. calling convention).
  • New behaviour: If the modeswitch PrefixedAttributes is enabled (which is the default in modes Delphi and DelphiUnicode) the directive clause in square brackets is no longer allowed.
  • Reason: As custom attributes are bound to a type/property in a way that looks ambiguous to a directive clause and this ambiguity is not easily solved in the parser it is better to disable this feature.
  • Remedy:
    • don't set (in non-Delphi modes) or disable modeswitch PrefixedAttributes (in Delphi modes) if you don't use attributes ({$modeswitch PrefixedAttributes-})
    • rework your directive clause:
// this
procedure Test; cdecl; [public,alias:'foo']
begin
end;

// becomes this
procedure Test; cdecl; public; alias:'foo';
begin
end;
  • svn: 42402

Type information contains reference to attribute table

  • Old behavior: The first field of the data represented by TTypeData is whatever the sub branch of the case statement for the type contains.
  • New behavior: The first field of the data represented by TTypeData is a reference to the custom attributes that are attributed to the type, only then the type specific fields follow.
  • Reason: Any type can have attributes, so it make sense to provide this is a common location instead of having to parse the different types.
  • Remedy:
    • If you use the records provided by the TypInfo unit no changes should be necessary (same for the Rtti unit).
    • If you directly access the binary data you need handle an additional Pointer field at the beginning of the TTypeData area and possibly correct the alignment for platforms that have strict alignment requirements (e.g. ARM or M68k).
  • svn: 42375

Explicit values for enumeration types are limited to low(longint) ... high(longint)

  • Old behavior: The compiler accepted every integer value as explicit enumeration value. The value was silently reduced to the longint range if it fell outside of that range
  • New behavior: The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.
  • Reason: Type TEnum = (a = $ffffffff); resulted in an enum with size 1 instead of 4 as would be expected, because $ffffffff was interpreted as "-1".
  • Remedy: Add Longint typecasts to values outside the valid range of a Longint.

Comp as a type rename of Int64 instead of an alias

  • Old behavior: On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (Comp = Int64).
  • New behavior: On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (Comp = type Int64).
  • Reason:
    • This allows overloads of Comp and Int64 methods/functions
    • This allows to better detect properties of type Comp
    • Compatibility with Delphi for Win64 which applied the same reasoning
  • Remedy: If you relied on Comp being able to be passed to Int64 variables/parameters either include typecasts or add overloads for Comp.
  • svn: 43775

Routines that only differ in result type

  • Old behaviour: It was possible to declare routines (functions/procedures/methods) that only differ in their result type.
  • New behaviour: It is no longer possible to declare routines that only differ in their result type.
  • Reason: It makes no sense to allow this as there are situations where the compiler will not be able to determine which function to call (e.g. a simple call to a function Foo without using the result).
  • Remedy: Correctly declare overloads.
  • Notes:
    • As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.
    • Operator overloads (especially assignment operators) that only differ in result type are still allowed.
  • svn: 45973

Open Strings mode enabled by default in mode Delphi

  • Old behaviour: The Open Strings feature (directive $OpenStrings or $P) was not enabled in mode Delphi.
  • New behaviour: The Open Strings feature (directive $OpenStrings or $P) is enabled in mode Delphi.
  • Reason: Delphi compatibility.
  • Remedy: If you have assembly routines with a var parameter of type ShortString then you also need to handle the hidden High parameter that is added for the Open String or you need to disable Open Strings for that routine.
  • git: 188cac3b

Unit changes

System - TVariantManager

  • Old behaviour: TVariantManager.olevarfromint has a source parameter of type LongInt.
  • New behaviour: TVariantManager.olevarfromint has a source parameter of type Int64.
  • Reason for change: 64-bit values couldn't be correctly converted to an OleVariant.
  • Remedy: If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.
  • svn: 41570

System - buffering of output to text files

  • Old behaviour: Buffering was disabled only for output to text files associated with character devices (Linux, BSD targets, OS/2), or for output to Input, Output and StdErr regardless of their possible redirection (Win32/Win64, AIX, Haiku, BeOS, Solaris).
  • New behaviour: Buffering is disabled for output to text files associated with character devices, pipes and sockets (the latter only if the particular target supports accessing sockets as files - Unix targets).
  • Reason for change: The same behaviour should be ensured on all supported targets whenever possible. Output to pipes and sockets should be performed immediately, equally to output to character devices (typically console) - in case of console users may be waiting for the output, in case of pipes and sockets some other program is waiting for this output and buffering is not appropriate. Seeking is not attempted in SeekEof implementation for files associated with character devices, pipes and sockets, because these files are usually not seekable anyway (instead, reading is performed until the end of the input stream is reached).
  • Remedy: Buffering of a particular file may be controlled programmatically / changed from the default behaviour if necessary. In particular, perform TextRec(YourTextFile).FlushFunc:=nil immediately after opening the text file (i.e. after calling Rewrite or after starting the program in case of Input, Output and StdErr) and before performing any output to this text to enable buffering using the default buffer, or TextRec(YourTextFile).FlushFunc:=TextRec(YourTextFile).FileWriteFunc to disable buffering.
  • svn: 46863

System - type returned by BasicEventCreate on Windows

  • Old behaviour: BasicEventCreate returns a pointer to a record which contains the Windows Event handle as well as the last error code after a failed wait. This record was however only provided in the implementation section of the System unit.
  • New behaviour: BasicEventCreate returns solely the Windows Event handle.
  • Reason for change: This way the returned handle can be directly used in the Windows Wait*-functions which is especially apparent in TEventObject.Handle.
  • Remedy: If you need the last error code after a failed wait, use GetLastOSError instead.
  • svn: 49068

System - Ref. count of strings

  • Old behaviour: Reference counter of strings was a SizeInt
  • New behaviour: Reference counter of strings is now a Longint on 64 Bit platforms and SizeInt on all other platforms.
  • Reason for change: Better alignment of strings
  • Remedy: Call System.StringRefCount instead of trying to access the ref. count field by pointer operations or other tricks.
  • git: ee10850a57

System.UITypes - function TRectF.Union changed to procedure

  • Old behaviour: function TRectF.Union(const r: TRectF): TRectF;
  • New behaviour: procedure TRectF.Union(const r: TRectF);
  • Reason for change: Delphi compatibility and also compatibility with TRect.Union
  • Remedy: Call class function TRectF.Union instead.
  • git: 5109f0ba

64-bit values in OleVariant

  • Old behaviour: If a 64-bit value (Int64, QWord) is assigned to an OleVariant its type is varInteger and only the lower 32-bit are available.
  • New behaviour: If a 64-bit value (Int64, QWord) is assigned to an OleVariant its type is either varInt64 or varQWord depending on the input type.
  • Reason for change: 64-bit values weren't correctly represented. This change is also Delphi compatible.
  • Remedy: Ensure that you handle 64-bit values correctly when using OleVariant.
  • svn: 41571

Classes TCollection.Move

  • Old behaviour: If a TCollection.Descendant called Move() this would invoke System.Move.
  • New behaviour: If a TCollection.Descendant called Move() this invokes TCollection.Move.
  • Reason for change: New feature in TCollection: move, for consistency with other classes.
  • Remedy: prepend the Move() call with the system unit name: System.move().
  • svn: 41795

Math Min/MaxSingle/Double

  • Old behaviour: MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.
  • New behaviour: The constants represent now the smallest/biggest positive normal numbers.
  • Reason for change: Consistency (this is also Delphi compatibility), see https://gitlab.com/freepascal.org/fpc/source/-/issues/36870.
  • Remedy: If the code really depends on the old values, rename them and use them as renamed.
  • svn: 44714

Random generator

  • Old behaviour: FPC uses a Mersenne twister generate random numbers
  • New behaviour: Now it uses Xoshiro128**
  • Reason for change: Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.
  • Remedy: When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.
  • git: 91cf1774

Types.TPointF.operator *

  • Old behaviour: for a, b: TPointF, a * b is a synonym for a.DotProduct(b): it returns a single, scalar product of two input vectors.
  • New behaviour: a * b does a component-wise multiplication and returns TPointF.
  • Reason for change: Virtually all technologies that have a notion of vectors use * for component-wise multiplication. Delphi with its System.Types is among these technologies.
  • Remedy: Use newly-introduced a ** b, or a.DotProduct(b) if you need Delphi compatibility.
  • git: f1e391fb

CocoaAll

CoreImage Framework Linking
  • Old behaviour: Starting with FPC 3.2.0, the CocoaAll unit linked caused the CoreImage framework to be linked.
  • New behaviour: The CocoaAll unit no longer causes the CoreImage framework to be linked.
  • Reason for change: The CoreImage framework is not available on OS X 10.10 and earlier (it's part of QuartzCore there, and does not exist at all on some even older versions).
  • Remedy: If you use functionality that is only available as part of the separate CoreImage framework, explicitly link it in your program using the {$linkframework CoreImage} directive.
  • svn: 45767

DB

TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008)
  • Old behaviour: TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).
  • New behaviour: TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).
  • Reason for change: native support for new data types introduced in MS SQL Server 2008 (like DATE, TIME, DATETIME2). FreeTDS client library version 0.95 or higher required.
  • svn: 42737
DB.TFieldType: new types added
  • Old behaviour: .
  • New behaviour: Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField
  • Reason for change: align with Delphi and open space for support of short integer and unsigned integer data types
  • svn: 47217, 47219, 47220, 47221; git: c46b45bf

DaemonApp

TDaemonThread
  • Old behaviour: The virtual method TDaemonThread.HandleControlCode takes a single DWord parameter containing the control code.
  • New behaviour: The virtual method TDaemonThread.HandleControlCode takes three parameters of which the first is the control code, the other two are an additional event type and event data.
  • Reason for change: Allow for additional event data to be passed along which is required for comfortable handling of additional control codes provided on Windows.
  • svn: 46327
TDaemon
  • Old behaviour: If an event handler is assigned to OnControlCode then it will be called if the daemon receives a control code.
  • New behaviour: If an event handler is assigned to OnControlCodeEvent and that sets the AHandled parameter to True then OnControlCode won't be called, otherwise it will be called if assigned.
  • Reason for change: This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.
  • svn: 46327

FileInfo

  • Old behaviour: The FileInfo unit is part of the fcl-base package.
  • New behaviour: The FileInfo unit is part of the fcl-extra package.
  • Reason for change: Breaks up a cycle in build dependencies after introducing a RC file parser into fcl-res. This should only affect users that compile trunk due to stale PPU files in the old location or that use a software distribution that splits the FPC packages (like Debian).
  • svn: 46392

Sha1

  • Old behaviour: Sha1file silently did nothing on file not found.
  • New behaviour: sha1file now raises sysconst.sfilenotfound exception on fle not found.
  • Reason for change: Behaviour was not logical, other units in the same package already used sysutils.
  • svn: 49166

Image

FreeType: include bearings and invisible characters into text bounds
  • Old behaviour: When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.
  • New behaviour: the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.
  • Reason for change: The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.
  • svn: 49629

Generics.Collections & Generics.Defaults

  • Old behaviour: Various methods had constref parameters.
  • New behaviour: constref parameters were changed to const parameters.
  • Reason for change:
    • Delphi compatibility
    • Better code generation especially for types that are smaller or equal to the Pointer size.
  • Remedy: Adjust parameters of method pointers or virtual methods.
  • git: 69349104

AArch64/ARM64

{-style comments no longer supported in assembler blocks

  • Old behaviour: The { character started a comment in assembler blocks, like in Pascal
  • New behaviour: The { character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.
  • Reason for change: Support has been added for register sets in the AArch64 assembler reader (for the ld1/ld2/../st1/st2/... instructions), which also start with {.
  • Remedy: Use (* or // to start comments
  • svn: 47116


Darwin/iOS

Previous release notes