Difference between revisions of "User Changes Trunk"
From Lazarus wiki
Jump to navigationJump to searchPascalDragon (talk | contribs) (correct svn revision) |
m (→Unit changes: sha1) |
||
(46 intermediate revisions by 10 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. | + | 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 === | === Language Changes === | ||
− | ==== | + | ==== Precedence of the IS operator changed ==== |
− | * '''Old behaviour''': | + | * '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators. |
− | * '''New behaviour''': | + | * '''New behaviour''': The IS operator has the same predence as the comparison operators. |
− | * '''Reason''': | + | * '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909]. |
− | * '''Remedy''': | + | * '''Remedy''': Add parenthesis where needed. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | ==== | + | === Implementation Changes === |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Property field access lists no longer allows classes ==== | ==== Property field access lists no longer allows classes ==== | ||
Line 102: | Line 28: | ||
** Switch the fields to records or objects | ** Switch the fields to records or objects | ||
** Use a method with inline modifier that will result in similar performance | ** Use a method with inline modifier that will result in similar performance | ||
− | * '''svn''': | + | * '''svn''': 40656 |
* '''Example''': The following code now fails: | * '''Example''': The following code now fails: | ||
− | <syntaxhighlight> | + | <syntaxhighlight lang="pascal"> |
unit Test; | unit Test; | ||
{$mode objfpc} | {$mode objfpc} | ||
Line 127: | Line 53: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | ==== | + | ==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ==== |
− | * '''Old behaviour''': | + | * '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array. |
− | * '''New behaviour''': | + | * '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode. |
− | * '''Reason''': | + | * '''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) | |
− | |||
− | |||
− | |||
− | * ''' | ||
− | == | + | <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 | + | * '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either. |
− | * '''New | + | * '''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''': | + | * '''Reason''': Delphi-compatibility. |
− | * '''Remedy''': | + | * '''Remedy''': Fix the range errors. |
− | * '''svn''': | + | * '''svn''': 42272, 42275 |
− | ==== | + | ==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ==== |
− | * '''Old | + | * '''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''': | + | * '''svn''': 42402 |
− | ==== | + | ==== Type information contains reference to attribute table ==== |
− | * '''Old behavior''': | + | * '''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''': | + | * '''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''': | + | * '''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''': | + | * '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64''). |
− | * '''New behavior''': | + | * '''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 |
− | * ''' | ||
− | |||
− | * | ||
− | * | ||
− | |||
− | |||
− | |||
− | * | ||
− | * | ||
− | * '''Remedy''': | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | * '''svn''': | ||
− | ==== | + | ==== Routines that only differ in result type ==== |
− | * '''Old | + | * '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type. |
− | * '''New | + | * '''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 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | * '''Remedy | ||
− | * ''' | ||
− | |||
− | |||
− | |||
− | * | ||
− | * | ||
− | * | ||
− | * '''svn''' | ||
=== Unit changes === | === Unit changes === | ||
Line 253: | Line 152: | ||
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''. | * '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''. | ||
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''. | * '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''. | ||
− | * '''Reason for change:''' 64-bit values couldn't be correctly converted to | + | * '''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. | * '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly. | ||
* '''svn:''' 41570 | * '''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 | ||
==== 64-bit values in OleVariant ==== | ==== 64-bit values in OleVariant ==== | ||
Line 265: | Line 180: | ||
* '''svn:''' 41571 | * '''svn:''' 41571 | ||
− | ==== | + | ==== Classes TCollection.Move ==== |
− | * '''Old behaviour:''' | + | * '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move. |
− | * '''New behaviour:''' | + | * '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move. |
− | * '''Reason for change:''' | + | * '''Reason for change:''' New feature in TCollection: move, for consistency with other classes. |
− | * '''Remedy:''' | + | * '''Remedy:''' prepend the Move() call with the system unit name: System.move(). |
+ | * '''svn:''' 41795 | ||
− | ==== | + | ==== Math Min/MaxSingle/Double ==== |
− | * '''Old behaviour:''' | + | * '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value. |
− | * '''New behaviour:''' | + | * '''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 ==== |
− | * '''Old behaviour | + | ===== CoreImage Framework Linking ===== |
− | * '''New behaviour:''' | + | * '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked. |
− | * '''Reason for change:''' | + | * '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked. |
− | * '''Remedy:''' | + | * '''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 ==== | ||
− | ===== | + | ===== 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 | |
− | |||
− | * '''Old behaviour | ||
− | |||
− | |||
− | |||
− | * ''' | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | * '''Reason for change''' | ||
− | * ''' | ||
− | ==== | + | ===== DB.TFieldType: new types added ===== |
− | + | * '''Old behaviour:''' . | |
− | * '''Old | + | * '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField |
− | * '''New | + | * '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types |
− | * '''Reason | + | * '''svn''': 47217 |
− | * ''' | ||
− | == | + | ==== 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''' | + | * '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code. |
− | * '''New behaviour''' | + | * '''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''' | + | * '''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''' | + | * '''Old behaviour:''' Sha1file silently did nothing on file not found. |
− | * '''New behaviour''' | + | * '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found. |
− | * '''Reason''' | + | * '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils. |
− | * ''' | + | * '''svn''': 49166 |
− | == | + | == 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 == | == Previous release notes == |
Revision as of 16:28, 10 April 2021
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
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
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
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
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
- Reason for change: align with Delphi and open space for support of short integer and unsigned integer data types
- svn: 47217
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
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