View source for User Changes Trunk

== About this page==

Listed below are intentional changes made to the FPC compiler (trunk) since the [[User_Changes_3.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]].

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 predence as the multiplication, division etc. operators.
* '''New behaviour''': The IS operator has the same predence as the comparison operators.
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].
* '''Remedy''': Add parenthesis where needed.

=== Implementation Changes ===

==== Property field access lists no longer allows classes ====
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.
* '''Reason''':
** Delphi compatibility
** This resulted in an internal error for published properties
* '''Remedy''':
** Switch the fields to records or objects
** Use a method with inline modifier that will result in similar performance
* '''svn''': 40656
* '''Example''': The following code now fails:
<syntaxhighlight lang="pascal">
unit Test;
{$mode objfpc}

interface

type
  TTest1 = class
    Field: String;
  end;

  TTest2 = class
  private
    fTest1: TTest1;
  public
    property Prop: String read fTest1.Field; // Error "Record or object type expected"
  end;

implementation

end.
</syntaxhighlight>

==== 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 [https://bugs.freepascal.org/view.php?id=35580 TStream.Read() overloads].
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' a
* '''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;

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.
</syntaxhighlight>
* '''svn''': 42118

==== Range checking for enumeration constants in Delphi mode ====
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.
* '''New behaviour''': Out-of-range enumeration constants cause an error in Delphi mode, even if range checking is disabled. Current Delphi versions (and even older ones, such as Delphi 7) behave the same.
* '''Reason''': Delphi-compatibility.
* '''Remedy''': Fix the range errors.
* '''svn''': 42272, 42275

==== 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;

// becomes this
procedure Test; cdecl; public; alias:'foo';
begin
end;
</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

=== 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

==== 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://bugs.freepascal.org/view.php?id=36870.
* '''Remedy:'''  If the code really depends on the old values, rename them and use them as renamed.
* '''svn:''' 44714

==== 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

== Darwin/iOS ==
=== The Darwin targets corresponding to iOS have been renamed to iOS ===
* '''Old behaviour:''' The Darwin/ARM and Darwin/AArch64 (ARM64) targets generated code for iOS running on those architectures.
* '''New behaviour:''' The Darwin/AArch64 (ARM64) target generates code for macOS running on AArch64. To generate code for iOS, use the new iOS target (-Tios)
* '''Reason for change:''' The switch of the macOS platform to AArch64 
* '''svn''': 45762

== Previous release notes ==
{{Navbar Lazarus Release Notes}}

[[Category:FPC User Changes by release]]
[[Category:Release Notes]]
[[Category:Troubleshooting]]