Difference between revisions of "User Changes Trunk"

From Free Pascal wiki
(xmlxsd unit splitted into xmlxsd and xmlxsdparser)
(AArch64/ARM64 - ''{''-style comments no longer supported in assembler blocks)
 
(333 intermediate revisions by 23 users not shown)
Line 1: Line 1:
 
== About this page==
 
== About this page==
  
Below you can find a list of intentional changes since the [[User_Changes_2.4.2|previous release]] that can change the behaviour of previously working code, along with why these changes were performed and how you can adapt your code if you are affected by them. The list of new features can be found [[FPC_New_Features_Trunk|here]].
+
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.  
  
== All systems ==
+
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].
  
===Usage Changes===
+
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.
  
==== Static keyword is enabled without switches and directives ====
+
== All systems ==
* '''Old behaviour''': Using the ''static'' keyword required passing the ''-St'' switch to the compiler or using the '' {$STATIC on}'' directive.
 
* '''New behaviour''': The ''static'' keyword is now always enabled.
 
* '''Effect''': The ''-St'' switch has been deprecated and the ''{$STATIC on/off}'' directive no longer exists.
 
* '''Reason''': The compiler can now always correctly determine whether ''static'' is used as a modifier or as a field name, and recent Delphi versions support ''static'' class methods without any special switches.
 
* '''Remedy''': Adjust your build scripts and source code by removing all ''-St'' parameters and and ''{$STATIC on/off}'' statements.
 
  
==== POINTERARITHMETICS modeswitch is replaced with POINTERMATH directive ====
+
=== Language Changes ===
* '''Old behaviour''': Pointer arithmetics was enabled in FPC/OBJFPC and partly (except using pointer as array) in DELPHI modes by default. To enable pointer arithmetics in other modes it was needed to use {$MODESWITCH POINTERARITHMETICS}.
 
* '''New behaviour''': Pointer arithmetics is enabled in FPC/OBJFPC modes and disabled in DELPHI mode. The new directive {$POINTERMATH ON/OFF} turns pointer arithmetic support in the compiler. Types declared with {$POINTERMATH ON} also support pointer arithmetics.
 
* '''Effect''': {$MODESWITCH POINTERARITHMETICS} is no longer exists. Pointer arithmetic is disabled in DELPHI mode.
 
* '''Reason''': Delphi compatibility.
 
* '''Remedy''': Check your source code for {$MODESWITCH POINTERARITHMETICS} directives and replace them with {$POINTERMATH ON}. If your source files are using DELPHI mode and you are using pointer arithmetic then add {$POINTERMATH ON} directive to your source files.
 
  
====Compiler no longer searches for utilities in the current directory====
+
==== Precedence of the IS operator changed ====
* '''Old behaviour''': The compiler first searched the current directory for external utilities (the assembler, linker, resource compiler, ...) before other locations (directory containing the compiler binary, directories in the PATH).
+
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.
* '''New behaviour''': The compiler will no longer search the current directory for external utilities, except when explicitly instructed to do so (via ''-FD.'', or if the current directory is in the PATH)
+
* '''New behaviour''': The IS operator has the same predence as the comparison operators.
* '''Reason''': The old behaviour was a security issue, since a rogue binary with the same name as a helper utility in the current directory (e.g., ''/tmp'' on a Unix-based system) could compromise your account.
+
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].
* '''Remedy''': Put external utilities in a fixed location on your system and add that directory to the path. Note that on most systems this is the case by default, and no configuration changes will be required.
+
* '''Remedy''': Add parenthesis where needed.
  
=== Language changes ===
+
=== Implementation Changes ===
  
==== Passing derived classes to var- and out-parameters====
+
==== 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}
  
* '''Old behaviour''': If a routine was declared with a var- or out-parameter of a certain class type, the compiler also allowed passing derived classes to this parameter.
+
interface
* '''New behaviour''': The compile-time type of a class passed to a routine now has to match the declared parameter type exactly in case of var- and out-parameters.
 
* '''Example''':
 
<delphi>
 
{$mode objfpc}
 
  
 
type
 
type
   ta = class
+
   TTest1 = class
 +
    Field: String;
 
   end;
 
   end;
  
   tb = class(ta)
+
   TTest2 = class
 +
  private
 +
    fTest1: TTest1;
 +
  public
 +
    property Prop: String read fTest1.Field; // Error "Record or object type expected"
 
   end;
 
   end;
  
var
+
implementation
  b: tb;
 
  
procedure test(var a: ta);
 
begin
 
  a:=ta.create;
 
  // now b contains an instance of type "ta"
 
end;
 
 
begin
 
  b:=nil;
 
  test(b);
 
 
end.
 
end.
</delphi>
+
</syntaxhighlight>
The compiler used to accept the above program, but now it will give an error at the call to ''test''.
 
* '''Reason''': As the example above demonstrates, allowing this behaviour circumvents the language's type checking. This change is also Delphi-compatible.
 
* '''Remedy''': Rewrite the affected code so it that all var/out-parameters and the class types passed to them match exactly. There are ways to circumvent the type checking at the caller side by using explicit type conversions, but using such hacks is strongly discouraged since the resulting code is not type-safe.
 
  
====''Array of const'' parameters and cdecl routines====
+
==== 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}''
 +
* '''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)
  
* '''Old behaviour''': It was possible to have non-external ''cdecl'' routines with an ''array of const'' parameter.
+
<syntaxhighlight lang="pascal">
* '''New behaviour''': ''Cdecl'' routines with an ''array of const'' parameter now always must be external.
+
{$mode objfpc}
* '''Reason''': In FPC, adding an ''array of const'' parameter to a ''cdecl'' routine has the same effect as adding the ''varargs'' modifier. It means that the routine takes a C-style variable number of arguments. There is however no way in (Free) Pascal to access these arguments on the callee side. This change means that both ''varargs'' and ''array of const'' are treated consistently, since ''varargs'' routines already had to be external.
+
type
* '''Remedy''': Remove the ''cdecl'' specifier and use a Pascal-style ''array of const'', or implement the routine in C and add ''external'' to the Pascal declaration.
+
  tdynarray = array of byte;
  
==== String constants longer than 255 chars ====
+
procedure test(var arr); overload;
* '''Old behaviour''': String constants longer than 255 chars were silently cut off after 255 chars under certain circumstances.
+
begin
* '''New behaviour''': String constants longer than 255 chars cause an error in ''$H-'' state, in ''$H+'' state an ansistring constant is generated.
+
  pbyte(arr)[0]:=1;
* '''Reason''': Cutting of strings silently sounds like bad behaviour of the compiler.
+
end;
* '''Remedy''': Manually truncate string constants longer than 255 chars or use ''$H+''
 
  
====Short/Ansistring typed constants containing widechars/unicodechars====
+
procedure test(arr: tdynarray); overload;
* '''Old behaviour''': The compiler accepted ''shortstring'' and ''ansistring'' typed constant declarations to which ''widestring'' or ''unicodestring'' constants were assigned (string constants containing widechars/unicodechars, i.e.,  character constants of the form ''#$xxx'', ''#$xxxx'' or ''#yyy'' with ''yyy > 255'', or character literals outside the ASCII range while the code page is different from the default one).
 
* '''New behaviour''': The compiler will reject such declarations now.
 
* '''Example''':
 
<delphi>
 
{$codepage utf8}
 
 
 
{ this example assumes that the source file has been saved using utf-8 encoding }
 
 
 
const
 
  s1: shortstring = 'éà';
 
  s2: ansistring = #$094#$06D;
 
  s3: ansistring = #267#543;
 
 
begin
 
begin
end.
+
  test[0]:=1;
</delphi>
+
end;
All three declarations above used to be accepted, but are now rejected. The reasons are that
 
* the string assigned to ''s1'' has been encoded as an utf-8 string and contains non-ASCII characters
 
* the string assigned to ''s2'' contains hexadecimal character constants declared with more than 2 digits
 
* the string assigned to ''s3'' contains character values > 255
 
In all cases, the practical upshot is that the string on the right hand side of the assignment will be treated as a wide/unicodestring constant at compile time.
 
* '''Reason''': The encoding of shortstrings and ansistrings is always the system (ansi) encoding at run time. This system encoding can be different every time the program is run, and hence cannot be determined at compile time. It is therefore not possible for the compiler to convert a wide/unicodestring constant to an ansi/shortstring at compile time. See also [http://bugs.freepascal.org/view.php?id=16219 bug report 16219].
 
* '''Remedy''': If you require the string's characters to contain particular ordinal values, declare the string constant as a sequence of byte-sized values (i.e., values <= 255, and in case of hexadecimal notation only use two digits), or do not use any ''{$codepage xxx}'' directive nor [http://unicode.org/faq/utf_bom.html#bom1 an UTF BOM]. In all other cases, declare the typed constant as a ''widestring'' or ''unicodestring''.
 
  
====Implicit "result" variable in MacPas mode====
 
* '''Old behaviour''': In MacPas mode, all functions could automatically access the function result via the implicitly defined ''result'' alias (like in Delphi and ObjFPC mode).
 
* '''New behaviour''': The ''result'' alias is no longer defined by default in MacPas mode.
 
* '''Reason''': It is not available in Mac Pascal compilers either, and can mask other identifiers thereby changing the behaviour of code.
 
* '''Remedy''': You can reenable the ''result'' alias by adding ''{$modeswitch result}'' to your program code (''after'' any ''{$mode macpas}'' statements), or by using the ''-Mresult'' command line option (''after'' any ''-Mmacpas'' parameter, and provided there are no ''{$mode xxx}'' directives in the source).
 
 
=== Implementation changes ===
 
 
====Order of parameters in RTTI====
 
* '''Old behaviour''': The order in which the parameter information for a function was stored in the RTTI depended on the function's calling convention. If the calling convention <u>on i386</u> passed parameters from left-to-right, parameters were stored from left to right (regardless of the actual platform, which was a bug in itself), otherwise they were stored from right to left.
 
* '''New behaviour''': The parameters are always stored from left to right in the RTTI, i.e., as they appear in the source code.
 
* '''Effect''': Code parsing RTTI information for the purpose of figuring out in which order to pass the parameters will no longer work.
 
* '''Reason''': Delphi compatibility, making the information more useful for IDEs.
 
* '''Remedy''': Adjust your code so it always expects parameters to appear in the RTTI ordered from left to right. In the future, we will also add the calling convention itself to the RTTI (like Delphi), so you can use that information to reorder the parameters in case you want to use this information to call the routine.
 
 
====Sizes of sets in TP/Delphi mode====
 
* '''Old behaviour''': {$packset fixed} was the default for all language modes. This packs a set of up to 32 elements in 4 bytes, and all other sets in 32 bytes.
 
* '''New behaviour''': The default in TP/Delphi mode is now {$packset 1}
 
* '''Effect''': In those language modes the size of sets with 1..8 elements will now be 1 byte, and the size of sets with 9..16 elements will be two bytes. Sets with 17..32 elements will remain 4 bytes, but after that every additional 8 elements the size will increase by 1 byte up to 249..256 elements, which will result in a set of 32 bytes.
 
* '''Reason''': TP/Delphi compatibility.
 
* '''Remedy''': If you have code written in TP/Delphi mode that depends on the old packset setting, add {$packset fixed} to the source (after setting the syntax mode to Delphi/TP, since the ''mode'' switching changes the ''packset'' setting). This is backward compatible with at least FPC 2.2.4 and later.
 
 
====Constants in mixed signed/unsigned 64 bit expressions====
 
* '''Old behaviour''':  Some comparisons involving a negative 64 bit constant and a unsigned 64 bit variable were handled incorrectly by the compiler: the negative constant was internally explicitly typecasted to the unsigned type.
 
* '''New behaviour''': The compiler will now correctly use the original value of the negative constant.
 
* '''Effect''': Some comparisons that previously evaluated to "true" at run time, may now evaluate to "false" at ''compile time''.
 
* '''Example''':
 
<delphi>
 
const
 
  // note that 64 bit hexadecimal constants are always parsed as int64
 
  // (also by previous FPC releases)
 
BIG_A = $AB09CD87EF653412;
 
 
var
 
var
q : qword;
+
  regulararray: array[1..1] of byte;
 
begin
 
begin
q := qword(BIG_A);
+
  regulararray[1]:=0;
if (q = BIG_A) then
+
  test(arr);
  writeln('same')
+
  writeln(arr[0]); // writes 0, because it calls test(tdynarr)
else
 
  writeln('different');
 
 
end.
 
end.
</delphi>
+
</syntaxhighlight>
The above program used to print 'same', but will now print 'different'
+
* '''svn''': 42118
* '''Reason''': The compiler must not automatically convert negative constants to positive equivalents like that.
 
* '''Remedy''': Explicitly typecast any constants that are supposed to be unsigned 64 bit constants to qword. E.g., in the above example, use ''BIG_A = qword($AB09CD87EF653412)''.
 
  
====Parameter passing and returning results on x86-64 platforms (except for Win64)====
+
==== 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
  
* '''Old behaviour''': The compiler did not correctly implement the [http://www.x86-64.org/documentation/abi.pdf official x86-64 ABI] for passing parameters and returning function results in all cases. In particular, records were always either passed/returned via integer registers or memory.
+
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====
* '''New behaviour''': The compiler now correctly adheres to the official x86-64 ABI under all circumstances on platforms that require this. In particular, certain records are now passed/returned via SSE registers.
+
* '''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).
* '''Effect''': Pure assembler routines based on the old conventions may no longer work on non-Win64 platforms. Win64 follows Microsoft's own variant of the x86-64 ABI and this one was already implemented correctly in the compiler, and hence has not been changed.
+
* '''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''': Interoperability with code generated by other compilers.
+
* '''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''': Adjust your assembler code so it expects parameters to be passed conform to the official x86-64 ABI
+
* '''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;
  
==== Overflow/Rangechecking for floating point constants ====
+
// becomes this
* '''Old behavior''': When a NaN floating point constant was assigned to a variable in {$R+} or {$Q+} mode, the compiler reported an error.
+
procedure Test; cdecl; public; alias:'foo';
* '''New behaviour''': {$R+} and {$Q+} no longer cause errors when assigning a NaN constant to a variable. The new $ieeeerrors setting can now be used to control whether or not such assignments should cause an error.
+
begin
* '''Reason''': Consistency, Delphi compatibility (it does not support the {$ieeeerrors+/-} setting, but it does not give an error based on the {$r/q} settings either) .
+
end;
* '''Remedy''': Add {$ieeeerrors+} to your code or add -C3 on the command line.
+
</syntaxhighlight>
 +
* '''svn''': 42402
  
=== Unit changes ===
+
==== 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.
  
==== xmlrpc unit and utils have been removed ====
+
==== 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
  
* '''Old behaviour''': There was an ''xmlrpc'' unit and a related demo program called ''mkxmlrpc''.
+
==== Additional ${include %xxx%} directives ====
* '''New behaviour''': These sources have been removed in svn trunk, and deprecated in the svn fixes branch.
+
* '''Old behaviour:''' The additional directives would have returned the content of an environment variable of the same name if it had existed, otherwise an empty string.
* '''Reason''': The code was unmaintained and had been broken for years, and has been replaced by new functionality in ''fcl-web'' and ''fcl-json''.
+
* '''New behaviour:''' The {$include %xxx%} directive now recognizes these additional internal variables:
* '''Remedy''': Use fcl-web or, if adapting the source code is not feasible, obtain the xmlrpc-related sources from older FPC versions.
+
** <syntaxhighlight lang="pascal" inline>{$include %currentRoutine%}</syntaxhighlight> expands to the name of the current routine ([[string]]).
 +
** <syntaxhighlight lang="pascal" inline>{$include %dateYear%}</syntaxhighlight> expands to the year number at time of compilation ([[Smallint|smallInt]]).
 +
** <syntaxhighlight lang="pascal" inline>{$include %dateMonth%}</syntaxhighlight> expands to the day number in month at time of compilation ([[Shortint|shortInt]]).
 +
** <syntaxhighlight lang="pascal" inline>{$include %timeHour%}</syntaxhighlight> expands to the number of seconds at time of compilation ([[Shortint|shortInt]]).
 +
** <syntaxhighlight lang="pascal" inline>{$include %timeMinute%}</syntaxhighlight> expands to the number of minutes at time of compilation ([[Shortint|shortInt]]).
 +
** <syntaxhighlight lang="pascal" inline>{$include %timeSecond%}</syntaxhighlight> expands to the number of seconds at time of compilation ([[Shortint|shortInt]]).
 +
* '''Reason:''' Adds to the existing {$include %fileName%}, {$include %line%} and {$include %date%} directives and is handy for debugging. 
 +
* '''Remedy:''' You can no longer name and use environment variable expansion with any of these names.
 +
* '''svn:''' 30873 (current routine), 38329 (date and time)
  
==== OpenSSL ====
+
==== 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
  
* '''Old behaviour''': The ''openssl'' unit contained an ''EVP_PKEY'' type.
+
=== Unit changes ===
* '''New behaviour''': The ''EVP_PKEY'' type has been renamed into ''PEVP_PKEY''.
 
* '''Reason''': Consistency with other similar types and with the original C declaration.
 
* '''Remedy''': Make the same typename change in your source code.
 
 
 
==== Graph unit aspect ratio changes in Arc and PieSlice ====
 
 
 
* '''Old behaviour''': Graph unit procedures Arc and PieSlice always assumed a 1:1 aspect ratio, regardless of current mode's aspect ratio.
 
* '''New behaviour''': Arc and PieSlice now respect the current aspect ratio.
 
* '''Reason''': Borland Pascal compatibility; better (i.e. more 'circular') looks of arcs and pie slices in modes with weird aspect ratios like 640x200; consistency with the Circle procedure, which already respects the current aspect ratio.
 
* '''Remedy''': This change is only likely to affect you, if you use a graphical mode with an aspect ratio, different than 1:1. Note that VGA 640x480 and higher modes usually always have a 1:1 aspect ratio. 320x200, 640x200, 640x350 and 640x400, however, do not. If you use one of these modes and, for some reason, don't want aspect ratio compensation in Arc and PieSlice, either call:
 
SetAspectRatio(10000, 10000)
 
immediately after InitGraph (this will also change the behaviour of Circle) or replace:
 
Arc(X, Y, StAngle, EndAngle, Radius) with Ellipse(X, Y, StAngle, EndAngle, Radius, Radius)
 
and
 
PieSlice(X, Y, StAngle, EndAngle, Radius) with Sector(X, Y, StAngle, EndAngle, Radius, Radius)
 
 
 
==== Graph unit aspect ratio changes in GraphDefaults ====
 
 
 
* '''Old behaviour''': The GraphDefaults procedure used to reset the current aspect ratio to 1:1, regardless of the current mode's default aspect ratio.
 
* '''New behaviour''': GraphDefaults no longer changes the current aspect ratio.
 
* '''Reason''': Borland Pascal compatibility; bug fix for applications that call GraphDefaults in modes with an aspect ratio different than 1:1 and still want to use aspect ratio compensation, since the old behaviour effectively disabled any aspect ratio compensation.
 
* '''Remedy''': If you want to reset the current aspect ratio to 1:1, just call:
 
SetAspectRatio(10000, 10000)
 
 
 
==== TThread.Suspend and TThread.Resume are deprecated ====
 
 
 
* '''Old behaviour''': Suspend would suspend the thread, if the platform allowed it, Resume would resume an explicitely suspended thread, or a thread created suspended.
 
* '''New behaviour''': Suspending running threads is deprecated. Creating threads suspended is still supported, and a new method START is added for this.
 
* '''Reason''': Both Embarcadero Delphi (D2010+) compatibility, and the unreliability and implementation trouble to implement running thread suspension on other platforms. Probably similar concerns played a part in Embarcaderoes decision.
 
* '''Remedy''': For threads created suspended, replace resume with start.  For suspending running threads: rewrite so this functionality is no longer needed.
 
 
 
Note that there are no short term plans to remove resume() to start suspended threads. If you want to share code with old Delphi versions, using resume will remain working for starting threads that were created suspended for several FPC releases to come. Just ignore the warning.
 
 
 
==== IInterface.QueryInterface, ._AddRef and ._Release definitions have been changed ====
 
  
* '''Old behaviour''': The IInterface.QueryInterface, ._AddRef and ._Release methods were defined stdcall and the IID was passed as const.
+
==== System - TVariantManager ====
* '''New behaviour''': These methods are defined stdcall on Windows and cdecl on the other operating systems. The IID parameter has become a constref.
 
* '''Reason''': These methods are used for communicating with COM on Windows. These changes make it possible to interface with XPCom from Mozilla, which is cross-platform and similar to COM/Corba.
 
* '''Remedy''': If one of these methods is overridden, they have to be defined as follows:
 
  
function QueryInterface({$IFDEF FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} IID: TGUID; out Obj): HResult; {$IF (not defined(WINDOWS)) AND (FPC_FULLVERSION>=20501)}cdecl{$ELSE}stdcall{$IFEND}; override;
+
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.
function _AddRef: Integer; {$IF (not defined(WINDOWS)) AND (FPC_FULLVERSION>=20501)}cdecl{$ELSE}stdcall{$IFEND}; override;
+
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.
function _Release: Integer; {$IF (not defined(WINDOWS)) AND (FPC_FULLVERSION>=20501)}cdecl{$ELSE}stdcall{$IFEND}; override;
+
* '''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
  
==== Default TFPPixelCanvas brush style ====
+
==== System - buffering of output to text files ====
  
* '''Old behaviour''': A brush in TFPPixelCanvas would start with the style bsClear
+
* '''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''': Now it starts with the style bsSolid
+
* '''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''': Starting with bsSolid is more intuitive and is also the state in which LCL brushes start.
+
* '''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''': Initialize the brush to bsClear after creating your TFPPixelCanvas if your code depended on it starting in this state.
+
* '''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
  
==== thread_count removed from system unit (win32,win64,wince, symbian, nativent) ====  
+
==== 64-bit values in OleVariant ====
  
* '''Old behaviour''': There was a variable called thread_count in the system unit of the targets win32,win64,wince, symbian, nativent
+
* '''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''': The variable has been removed.
+
* '''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''': The behaviour of the variable was wrong and cannot be fixed, see also http://bugs.freepascal.org/view.php?id=18089
+
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.
* '''Remedy''': Since the value of the variable was unpredictable, there was probably no use of it.
+
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.
 +
* '''svn:''' 41571
  
==== Locale global variables are deprecated ====  
+
==== 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
  
* '''Old behaviour''': For every locale configuration a variable alias existed (currencystring, *dateformat) using an "absolute" modifier.
+
==== Math Min/MaxSingle/Double ====
* '''New behaviour''': These variable now have the "deprecated" modifier, and a warning is emitted if you use one.
+
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.
* '''Reason''': FPC has supported the use of these variables in a record since before 2000 called DefaultFormatSettings, Delphi XE now follows suit with "Formatsettings". In time this might remove the need for "absolute" usage.
+
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.
* '''Remedy''': Use (Default)Formatsettings as much as possible. Note that that it will still be quite some time before these are actually removed.
+
* '''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
  
==== Glut.FreeGlut function renamed to UnloadGlut ====  
+
==== 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
  
* '''Old behaviour''': Glut unit contained a function called FreeGlut.
+
==== DB ====
* '''New behaviour''': This function is now renamed to UnloadGlut.
+
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====
* '''Reason''': We now include a FreeGlut unit, exposing http://freeglut.sourceforge.net/ -specific functionality. Function name "FreeGlut" inside Glut unit would cause name clashes and confusion (as it's not related to freeglut library).
+
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).
* '''Remedy''': Make the same rename in your source code.
+
* '''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
  
==== xmlxsd unit splitted into xmlxsd and xmlxsdparser ====
+
==== 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
  
* '''Old behaviour''': xmlxsd contained functions for parsing xml xsd types and helper functions for libxml2.
+
===== TDaemon =====
* '''New behaviour''': xmlxsd contains only the helper functions for libxml2, all the parser functions are moved to the xmlxsdparser unit.
+
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.
* '''Reason''': xmlxsd allways required the external library libxml2. But if somebody was using just the xsd type parser code, he had to include the libxml2 library also. Now all the xsd type parser functions are in xmlxsdparser. This new unit is not depandant of the external libxml2 library.
+
* '''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.
* '''Remedy''': If you are interested in the full libxml2 and xsd functionality, simply add xmlxsdparser to the uses list (besides xmlxsd). If you are interested only in the xsd type parser code, remove xmlxsd (and maybe libxml2) unit and use only xmlxsdparser.
+
* '''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
  
==x86 platforms ==
+
==== 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
  
===Operation size of pushf/popf/pusha/popa in Intel-style inline assembly===
+
== 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 default operation size of the ''pushf/popf/pusha/popa'' in Intel-style inline assembly was the native size (32 bit on i386, 64 bit on x86-64).
 
* '''New behaviour''': The default operation size of these opcodes is now always 16 bit in Intel-style inline assembly. In AT&T-style inline assembly, the size remains the native size.
 
* '''Reason''': This is how the behaviour of these opcodes is defined in the Intel manuals, and it is also Delphi-compatible. The behaviour was not changed in AT&T-inline assembly because that dialect defines the default size of these operations as the native size.
 
* '''Remedy''': Explicitly specify the size when using such operations, e.g. ''pushfd'', ''popfq'', ''pushad'', ... Note that ''pusha*/popa*'' do not exist on x86-64, and neither do ''pushfd/popfd'' (the compiler previously however erroneously accepted these opcodes when compiling for x86-64).
 
  
==x86-64 platforms ==
+
== 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
  
===Const parameter passing on non-Win64 platforms===
+
== Previous release notes ==
 +
{{Navbar Lazarus Release Notes}}
  
* '''Old behaviour''': All record parameters defined as ''const'' were passed by value.
+
[[Category:FPC User Changes by release]]
* '''New behaviour''': For calling conventions other than ''cdecl'' and ''cppdecl'', ''const'' record parameters are now passed by reference if they should be passed via memory according to the x86-64 ABI. Note that except for ''cdecl'' and ''cppdecl'', the behaviour of ''const'' is not defined and may change at any time.
+
[[Category:Release Notes]]
* '''Reason''': Performance.
+
[[Category:Troubleshooting]]
* '''Remedy''': In most cases, this change will not require any changes to existing code. The only exception is if you have assembler routines with ''const'' record parameters. In this case, the assembler code may have to be modified to expect a pointer to the record under the circumstances mentioned above. A better modification would be to remove the ''const'' altogether from any assembler routines and either use a value parameter or [[FPC_New_Features_Trunk#Constref_parameter_modifier|constref]], which respectively guarantee passing by value and passing by reference.
 

Latest revision as of 16:18, 17 October 2020

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 predence as the multiplication, division etc. operators.
  • New behaviour: The IS operator has the same predence as the comparison operators.
  • Reason: Bug, see [1].
  • 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:
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.

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

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:
// 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

Additional ${include %xxx%} directives

  • Old behaviour: The additional directives would have returned the content of an environment variable of the same name if it had existed, otherwise an empty string.
  • New behaviour: The {$include %xxx%} directive now recognizes these additional internal variables:
    • {$include %currentRoutine%} expands to the name of the current routine (string).
    • {$include %dateYear%} expands to the year number at time of compilation (smallInt).
    • {$include %dateMonth%} expands to the day number in month at time of compilation (shortInt).
    • {$include %timeHour%} expands to the number of seconds at time of compilation (shortInt).
    • {$include %timeMinute%} expands to the number of minutes at time of compilation (shortInt).
    • {$include %timeSecond%} expands to the number of seconds at time of compilation (shortInt).
  • Reason: Adds to the existing {$include %fileName%}, {$include %line%} and {$include %date%} directives and is handy for debugging.
  • Remedy: You can no longer name and use environment variable expansion with any of these names.
  • svn: 30873 (current routine), 38329 (date and time)

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

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

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

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

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

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