https://wiki.freepascal.org/api.php?action=feedcontributions&user=PascalDragon&feedformat=atomLazarus wiki - User contributions [en]2024-03-28T12:19:09ZUser contributionsMediaWiki 1.35.6https://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=158222User Changes Trunk2024-02-09T16:32:18Z<p>PascalDragon: Fix typos</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same precedence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same precedence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
==== Visibilities of members of generic specializations ====<br />
* '''Old behaviour''': When a generic is specialized then visibility checks are handled as if the generic was declared in the current unit.<br />
* '''New behaviour''': When a generic is specialized then visibility checks are handled according to where the generic is declared.<br />
* '''Reason''': Delphi-compatibility, but also a bug in how visibilities are supposed to work.<br />
* '''Remedy''': Rework your code to adhere to the new restrictions.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
==== Open Strings mode enabled by default in mode Delphi ====<br />
* '''Old behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') was not enabled in mode Delphi.<br />
* '''New behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') is enabled in mode Delphi.<br />
* '''Reason:''' Delphi compatibility.<br />
* '''Remedy:''' If you have assembly routines with a ''var'' parameter of type ''ShortString'' then you also need to handle the hidden ''High'' parameter that is added for the Open String or you need to disable Open Strings for that routine.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/188cac3bc6dc666167aacf47fedff1a81d378137 188cac3b]<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068<br />
<br />
==== System - Ref. count of strings ====<br />
<br />
* '''Old behaviour:''' Reference counter of strings was a ''SizeInt''<br />
* '''New behaviour:''' Reference counter of strings is now a ''Longint'' on 64 Bit platforms and ''SizeInt'' on all other platforms.<br />
* '''Reason for change:''' Better alignment of strings<br />
* '''Remedy:''' Call ''System.StringRefCount'' instead of trying to access the ref. count field by pointer operations or other tricks.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e ee10850a57]<br />
<br />
==== System.UITypes - function TRectF.Union changed to procedure ====<br />
<br />
* '''Old behaviour:''' ''function TRectF.Union(const r: TRectF): TRectF;''<br />
* '''New behaviour:''' ''procedure TRectF.Union(const r: TRectF);''<br />
* '''Reason for change:''' Delphi compatibility and also compatibility with TRect.Union<br />
* '''Remedy:''' Call ''class function TRectF.Union'' instead.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/5109f0ba444c85d2577023ce5fbdc2ddffc267c8 5109f0ba]<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://gitlab.com/freepascal.org/fpc/source/-/issues/36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== Random generator ====<br />
* '''Old behaviour:''' FPC uses a Mersenne twister generate random numbers<br />
* '''New behaviour:''' Now it uses Xoshiro128**<br />
* '''Reason for change:''' Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.<br />
* '''Remedy:''' When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.<br />
* '''git:''' 91cf1774<br />
<br />
==== Types.TPointF.operator * ====<br />
* '''Old behaviour:''' for <code>a, b: TPointF</code>, <code>a * b</code> is a synonym for <code>a.DotProduct(b)</code>: it returns a <code>single</code>, scalar product of two input vectors.<br />
* '''New behaviour:''' <code>a * b</code> does a component-wise multiplication and returns <code>TPointF</code>.<br />
* '''Reason for change''': Virtually all technologies that have a notion of vectors use <code>*</code> for component-wise multiplication. Delphi with its <code>System.Types</code> is among these technologies.<br />
* '''Remedy:''' Use newly-introduced <code>a ** b</code>, or <code>a.DotProduct(b)</code> if you need Delphi compatibility.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/f1e391fb415239d926c4f23babe812e67824ef95 f1e391fb]<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217, 47219, 47220, 47221; '''git''': c46b45bf<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
==== Sha1 ====<br />
* '''Old behaviour:''' Sha1file silently did nothing on file not found.<br />
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.<br />
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.<br />
* '''svn''': 49166<br />
<br />
==== Image ====<br />
===== FreeType: include bearings and invisible characters into text bounds =====<br />
* '''Old behaviour:''' When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.<br />
* '''New behaviour:''' the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.<br />
* '''Reason for change:''' The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.<br />
* '''svn''': 49629<br />
<br />
==== Generics.Collections & Generics.Defaults ====<br />
* '''Old behaviour:''' Various methods had '''constref''' parameters.<br />
* '''New behaviour:''' '''constref''' parameters were changed to '''const''' parameters.<br />
* '''Reason for change:'''<br />
** Delphi compatibility<br />
** Better code generation especially for types that are smaller or equal to the ''Pointer'' size.<br />
* '''Remedy:''' Adjust parameters of method pointers or virtual methods.<br />
* '''git''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/693491048bf2c6f9122a0d8b044ad0e55382354d 69349104]<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=158221User Changes Trunk2024-02-09T16:32:00Z<p>PascalDragon: Documented change regarding visibilities of members of specializations</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
==== Visibilities of members of generic specializations ====<br />
* '''Old behaviour''': When a generic is specialized then visibility checks are handled as if the generic was declared in the current unit.<br />
* '''New behaviour''': When a generic is specialized then visibility checks are handled according to where the generic is declared.<br />
* '''Reason''': Delphi-compatibility, but also a bug in how visibilities are supposed to work.<br />
* '''Remedy''': Rework your code to adhere to the new restrictions.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
==== Open Strings mode enabled by default in mode Delphi ====<br />
* '''Old behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') was not enabled in mode Delphi.<br />
* '''New behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') is enabled in mode Delphi.<br />
* '''Reason:''' Delphi compatibility.<br />
* '''Remedy:''' If you have assembly routines with a ''var'' parameter of type ''ShortString'' then you also need to handle the hidden ''High'' parameter that is added for the Open String or you need to disable Open Strings for that routine.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/188cac3bc6dc666167aacf47fedff1a81d378137 188cac3b]<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068<br />
<br />
==== System - Ref. count of strings ====<br />
<br />
* '''Old behaviour:''' Reference counter of strings was a ''SizeInt''<br />
* '''New behaviour:''' Reference counter of strings is now a ''Longint'' on 64 Bit platforms and ''SizeInt'' on all other platforms.<br />
* '''Reason for change:''' Better alignment of strings<br />
* '''Remedy:''' Call ''System.StringRefCount'' instead of trying to access the ref. count field by pointer operations or other tricks.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e ee10850a57]<br />
<br />
==== System.UITypes - function TRectF.Union changed to procedure ====<br />
<br />
* '''Old behaviour:''' ''function TRectF.Union(const r: TRectF): TRectF;''<br />
* '''New behaviour:''' ''procedure TRectF.Union(const r: TRectF);''<br />
* '''Reason for change:''' Delphi compatibility and also compatibility with TRect.Union<br />
* '''Remedy:''' Call ''class function TRectF.Union'' instead.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/5109f0ba444c85d2577023ce5fbdc2ddffc267c8 5109f0ba]<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://gitlab.com/freepascal.org/fpc/source/-/issues/36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== Random generator ====<br />
* '''Old behaviour:''' FPC uses a Mersenne twister generate random numbers<br />
* '''New behaviour:''' Now it uses Xoshiro128**<br />
* '''Reason for change:''' Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.<br />
* '''Remedy:''' When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.<br />
* '''git:''' 91cf1774<br />
<br />
==== Types.TPointF.operator * ====<br />
* '''Old behaviour:''' for <code>a, b: TPointF</code>, <code>a * b</code> is a synonym for <code>a.DotProduct(b)</code>: it returns a <code>single</code>, scalar product of two input vectors.<br />
* '''New behaviour:''' <code>a * b</code> does a component-wise multiplication and returns <code>TPointF</code>.<br />
* '''Reason for change''': Virtually all technologies that have a notion of vectors use <code>*</code> for component-wise multiplication. Delphi with its <code>System.Types</code> is among these technologies.<br />
* '''Remedy:''' Use newly-introduced <code>a ** b</code>, or <code>a.DotProduct(b)</code> if you need Delphi compatibility.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/f1e391fb415239d926c4f23babe812e67824ef95 f1e391fb]<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217, 47219, 47220, 47221; '''git''': c46b45bf<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
==== Sha1 ====<br />
* '''Old behaviour:''' Sha1file silently did nothing on file not found.<br />
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.<br />
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.<br />
* '''svn''': 49166<br />
<br />
==== Image ====<br />
===== FreeType: include bearings and invisible characters into text bounds =====<br />
* '''Old behaviour:''' When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.<br />
* '''New behaviour:''' the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.<br />
* '''Reason for change:''' The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.<br />
* '''svn''': 49629<br />
<br />
==== Generics.Collections & Generics.Defaults ====<br />
* '''Old behaviour:''' Various methods had '''constref''' parameters.<br />
* '''New behaviour:''' '''constref''' parameters were changed to '''const''' parameters.<br />
* '''Reason for change:'''<br />
** Delphi compatibility<br />
** Better code generation especially for types that are smaller or equal to the ''Pointer'' size.<br />
* '''Remedy:''' Adjust parameters of method pointers or virtual methods.<br />
* '''git''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/693491048bf2c6f9122a0d8b044ad0e55382354d 69349104]<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=156676FPC New Features Trunk2023-06-23T14:33:41Z<p>PascalDragon: Documented type helper extension</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/test<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Array constructors for static arrays ====<br />
* '''Overview''': Array constructors can be used to assign values to static arrays.<br />
* '''Notes''':<br />
** The array constructor needs to have the same amount of elements as the static array.<br />
** The first element of the array constructor will be placed at the location of the first element of the static array (e.g. if the array starts at -1 the first element will be at that location).<br />
** Arrays with enumeration index are supported as well.<br />
* '''svn''': 46891, 46901<br />
* '''Example''': https://gitlab.com/freepascal.org/fpc/source/-/tree/main/tests/test/tarrconstr16.pp<br />
<br />
==== "Align" modifier support for record definitions ====<br />
* '''Overview''': It is now possible to add an '''Align X''' modifier at the end of a record definition to indicate that the record as a whole should be aligned to a particular boundary.<br />
* '''Notes''':<br />
** Should be Delphi compatible, although documentation is not available ([https://web.archive.org/web/20171221044023/http://qc.embarcadero.com/wc/qcmain.aspx?d=87283 "semi-official" reference]; the mentioned issue does not exist in the FPC implementation).<br />
** This does not influence the alignment of the individual fields, which are still aligned according to the current ''{$packrecords y}''/''{$align y}'' settings.<br />
** X can be 1, 2, 4, 8, 16, 32 or 64.<br />
* '''svn''': 47892<br />
* '''Example''': https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw28927.pp?view=markup&pathrev=47892<br />
<br />
==== Support for binary literals in Delphi mode ====<br />
* '''Overview''': It is now possible to use binary literals ('%' as prefix) in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39503 #39503]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
b: byte;<br />
begin<br />
b:=%11001001;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for Digit Separator ====<br />
* '''Overview''': It is now possible to use the Digit Separator ('_') with the ''underscoreisseparator'' modeswitch. It is also enabled by default in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39504 #39504]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
i: Integer;<br />
r: Real;<br />
begin<br />
i := %1001_1001;<br />
i := &121_102;<br />
i := 1_123_123;<br />
i := $1_123_123; <br />
r := 1_123_123.000_000;<br />
r := 1_123_123.000_000e1_2;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for forward declarations of generic types ====<br />
* '''Overview''': It is now possible to use forward declarations for generic classes and interfaces like is possible for non-generic classes and interfaces.<br />
* '''Notes''':<br />
** Generic type constraints and const declarations need to be used for both the forward and the final implementation like is necessary for global generic routines.<br />
** This is Delphi-compatible.<br />
* '''Commit''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/2a5023508a2bc4ff3ba4f3a0ca16366d3df86db8 2a502350]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
generic TTest<T> = class;<br />
generic TFoo<T: class> = class;<br />
generic TBar<const N: LongInt> = class;<br />
<br />
TSomething = class<br />
fTest: specialize TTest<LongInt>;<br />
fFoo: specialize TFoo<TObject>;<br />
fBar: specialize TBar<42>;<br />
end;<br />
<br />
generic TTest<T> = class end;<br />
generic TFoo<T: class> = class end;<br />
generic TBar<const N: LongInt> = class end;<br />
<br />
begin<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for Function References and Anonymous Functions ====<br />
* '''Function References''': Function References (also applicable names are Procedure References and Routine References, in the following only Function References will be used) are types that can take a function (or procedure or routine), method, function variable (or procedure variable or routine variable), method variable, nested function (or nested procedure or nested routine) or an anonymous function (or anonymous procedure or anonymous routine) as a value. The function reference can then be used to call the provided function just like other similar routine pointer types. In contrast to these other types nearly all function-like constructs can be assigned to it (the only exception are nested function variables (or nested procedure variables or nested routine variables), more about that later on) and then used or stored.<br />
* '''Anonymous Functions''': Anonymous Functions (or Anonymous Procedures or Anonymous Routines, in the following simply Anonymous Functions) are routines that have no name associated with them and are declared in the middle of a code block (for example on the right side of an expression or as a parameter for a function call). However they can just as well be called directly like a nested function (or nested procedure or nested routine) would.<br />
* '''More Information and Examples''': [https://forum.lazarus.freepascal.org/index.php/topic,59468.0.html Feature announcement: Function References and Anonymous Functions]<br />
* '''GitLab Issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/24481 #24481]<br />
<br />
==== Descendant type helpers can extend type aliases ====<br />
* '''Overview''': A type helper that descends from another type helper can now extend a unique type alias of the type the inherited type helper extends. This way a type helper for the original type can be made available for the type alias as well.<br />
* '''Notes''':<br />
** The type alias the descendant extends does not need to be a ''direct'' type alias of the parent's extended type.<br />
** The other way around is not allowed: a type helper that inherits from another helper which extends a unique type alias can not extend the base type.<br />
* '''Example''': See the [https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/tthlp30.pp test] for the feature.<br />
* '''Commit''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/7133ad7ecc46700618193adff85cef84682355b0 7133ad7e]<br />
<br />
=== Units ===<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the user changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented for macOS.<br />
* '''Notes''': Delphi compatible, was already implemented for Windows, Linux and Android and finally for macOS now. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 49323<br />
<br />
==== Objects ====<br />
===== TRawByteStringCollection =====<br />
* '''Overview''': A new object type TRawByteStringCollection, similar to TStringCollection, but works with RawByteString/AnsiString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TUnicodeStringCollection =====<br />
* '''Overview''': A new object type TUnicodeStringCollection, similar to TStringCollection, but works with UnicodeString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TStream methods for reading and writing RawByteString and UnicodeString =====<br />
* '''Overview''': New methods have been added to TStream for reading and writing RawByteString/AnsiString and UnicodeString types.<br />
* '''Notes''': The following methods have been added:<br />
FUNCTION TStream.ReadRawByteString: RawByteString;<br />
FUNCTION TStream.ReadUnicodeString: UnicodeString;<br />
PROCEDURE TStream.WriteRawByteString (Const S: RawByteString);<br />
PROCEDURE TStream.WriteUnicodeString (Const S: UnicodeString);<br />
RawByteStrings are written to the stream as a 16-bit code page, followed by 32-bit length, followed by the string contents. UnicodeStrings are written as a 32-bit length (the number of 16-bit UTF-16 code units needed to encode the string), followed by the string itself in UTF-16.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Free Vision ====<br />
===== Unicode support =====<br />
* '''Overview''': Unicode versions of the Free Vision units have been added.<br />
* '''Notes''': The Unicode versions of the units have the same name as their non-Unicode counterparts, but with an added 'U' prefix in the beginning of their name. For example, the Unicode version of the 'app' unit is 'uapp', the Unicode version of 'views' is 'uviews', etc. The Unicode versions of the units use the UnicodeString type, instead of shortstrings and pchars. Mixing Unicode and non-Unicode Free Vision units in the same program is not supported and will not work.<br />
* '''More information''': [[Free_Vision#Unicode_version]]<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Video ====<br />
===== Unicode output support =====<br />
* '''Overview''': Unicode video buffer support has been added to the Video unit.<br />
* '''Notes''': To use the Unicode video buffer, you must call InitEnhancedVideo instead of InitVideo and finalize the unit with DoneEnhancedVideo instead of DoneVideo. After initializing with InitEnhancedVideo, you must use the EnhancedVideoBuf array instead of VideoBuf. On non-Unicode operating systems, the Video unit will automatically translate Unicode characters to the console code page. This is done transparently to the user application, so new programs can always use EnhancedVideoBuf, without worrying about compatibility.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Keyboard ====<br />
===== Unicode keyboard input support =====<br />
* '''Overview''': Unicode keyboard input support has been added to the Keyboard unit.<br />
* '''Notes''': After initializing the unit normally via InitKeyboard, you can obtain enhanced key events, which include Unicode character information, as well as an enhanced shift state. To get enhanced key events, use GetEnhancedKeyEvent or PollEnhancedKeyEvent. They return a TEnhancedKeyEvent, which is a record with these fields:<br />
TEnhancedKeyEvent = record<br />
VirtualKeyCode: Word; { device-independent identifier of the key }<br />
VirtualScanCode: Word; { device-dependent value, generated by the keyboard }<br />
UnicodeChar: WideChar; { the translated Unicode character }<br />
AsciiChar: Char; { the translated ASCII character }<br />
ShiftState: TEnhancedShiftState;<br />
Flags: Byte;<br />
end;<br />
<br />
TEnhancedShiftState is a set of TEnhancedShiftStateElement, which is defined as:<br />
TEnhancedShiftStateElement = (<br />
essShift, { either Left or Right Shift is pressed }<br />
essLeftShift,<br />
essRightShift,<br />
essCtrl, { either Left or Right Ctrl is pressed }<br />
essLeftCtrl,<br />
essRightCtrl,<br />
essAlt, { either Left or Right Alt is pressed, but *not* AltGr }<br />
essLeftAlt,<br />
essRightAlt, { only on keyboard layouts, without AltGr }<br />
essAltGr, { only on keyboard layouts, with AltGr instead of Right Alt }<br />
essCapsLockPressed,<br />
essCapsLockOn,<br />
essNumLockPressed,<br />
essNumLockOn,<br />
essScrollLockPressed,<br />
essScrollLockOn<br />
);<br />
<br />
A special value NilEnhancedKeyEvent is used to indicate no key event available in the result of PollEnhancedKeyEvent:<br />
{ The Nil value for the enhanced key event }<br />
NilEnhancedKeyEvent: TEnhancedKeyEvent = (<br />
VirtualKeyCode: 0;<br />
VirtualScanCode: 0;<br />
UnicodeChar: #0;<br />
AsciiChar: #0;<br />
ShiftState: [];<br />
Flags: 0;<br />
);<br />
<br />
* '''git:''' 0b8a0fb4<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Support for symbolicating Dwarf backtraces ===<br />
* '''Overview''': The -gl option now works with DWARF debug information on Darwin. This is the default for non-PowerPC Darwin targets, and the only support format for ARM and 64 bit Darwin targets.<br />
* '''Notes''': You have to also use the -Xg command line option when compiling the main program or library, to generate a .dSYM bundle that contains all debug information. You can also do this manually by calling ''dsymutil''<br />
* '''svn''': 49140<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Darwin/AArch64 (only macOS; iOS has not been tested), Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for address sanitizer (asan) through LLVM ===<br />
* '''Overview''': The compiler allows to check code with the LLVM address sanitizer.<br />
* '''Notes''': The LLVM address sanitizer is supported for all 64 bit targets supported by the LLVM code generator.<br />
* '''More information''':<br />
** [[LLVM]]<br />
** [https://en.wikipedia.org/wiki/AddressSanitizer Address Sanitizer on Wikipedia]<br />
* '''git''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/403292a13151dbc265748d2119f9d1bd52fb9d54 403292a1]<br />
<br />
=== Support for the Z80 ===<br />
* '''Overview''': Support has been added for generating Z80 code.<br />
* '''More information''': [[Z80]]<br />
<br />
=== Support for the WebAssembly target ===<br />
* '''Overview''': Support has been added for generating WebAssembly code.<br />
* '''More information''': [[WebAssembly/Compiler]]<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=154884User Changes Trunk2022-12-23T16:14:11Z<p>PascalDragon: Documented change of parameters in Generics.* from constref to const</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
==== Open Strings mode enabled by default in mode Delphi ====<br />
* '''Old behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') was not enabled in mode Delphi.<br />
* '''New behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') is enabled in mode Delphi.<br />
* '''Reason:''' Delphi compatibility.<br />
* '''Remedy:''' If you have assembly routines with a ''var'' parameter of type ''ShortString'' then you also need to handle the hidden ''High'' parameter that is added for the Open String or you need to disable Open Strings for that routine.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/188cac3bc6dc666167aacf47fedff1a81d378137 188cac3b]<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068<br />
<br />
==== System - Ref. count of strings ====<br />
<br />
* '''Old behaviour:''' Reference counter of strings was a ''SizeInt''<br />
* '''New behaviour:''' Reference counter of strings is now a ''Longint'' on 64 Bit platforms and ''SizeInt'' on all other platforms.<br />
* '''Reason for change:''' Better alignment of strings<br />
* '''Remedy:''' Call ''System.StringRefCount'' instead of trying to access the ref. count field by pointer operations or other tricks.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e ee10850a57]<br />
<br />
==== System.UITypes - function TRectF.Union changed to procedure ====<br />
<br />
* '''Old behaviour:''' ''function TRectF.Union(const r: TRectF): TRectF;''<br />
* '''New behaviour:''' ''procedure TRectF.Union(const r: TRectF);''<br />
* '''Reason for change:''' Delphi compatibility and also compatibility with TRect.Union<br />
* '''Remedy:''' Call ''class function TRectF.Union'' instead.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/5109f0ba444c85d2577023ce5fbdc2ddffc267c8 5109f0ba]<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== Random generator ====<br />
* '''Old behaviour:''' FPC uses a Mersenne twister generate random numbers<br />
* '''New behaviour:''' Now it uses Xoshiro128**<br />
* '''Reason for change:''' Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.<br />
* '''Remedy:''' When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.<br />
* '''git:''' 91cf1774<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217, 47219, 47220, 47221; '''git''': c46b45bf<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
==== Sha1 ====<br />
* '''Old behaviour:''' Sha1file silently did nothing on file not found.<br />
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.<br />
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.<br />
* '''svn''': 49166<br />
<br />
==== Image ====<br />
===== FreeType: include bearings and invisible characters into text bounds =====<br />
* '''Old behaviour:''' When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.<br />
* '''New behaviour:''' the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.<br />
* '''Reason for change:''' The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.<br />
* '''svn''': 49629<br />
<br />
==== Generics.Collections & Generics.Defaults ====<br />
* '''Old behaviour:''' Various methods had '''constref''' parameters.<br />
* '''New behaviour:''' '''constref''' parameters were changed to '''const''' parameters.<br />
* '''Reason for change:'''<br />
** Delphi compatibility<br />
** Better code generation especially for types that are smaller or equal to the ''Pointer'' size.<br />
* '''Remedy:''' Adjust parameters of method pointers or virtual methods.<br />
* '''git''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/693491048bf2c6f9122a0d8b044ad0e55382354d 69349104]<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=TARGET_Embedded&diff=154425TARGET Embedded2022-10-11T05:34:39Z<p>PascalDragon: Expanded documentation about the $Memory directive</p>
<hr />
<div>{{Embedded}}<br />
<br />
This is an overview of using FPC on embedded systems without an operating system. The embedded target is still under development and only a few microcontroller families are supported. These are ARM (several architectures), AVR, PIC32MX (MIPSel), Xtensa (ESP32) and Z80. The embedded target targets systems which are ''without any operating system'' and typically only have several kBs of RAM and several dozens of kB of flash. A typical target is the LPC family of NXP with popular members like the LPC2124 with 16 kB RAM and 256 kB flash using the ARM7 instruction set.<br />
<br />
== Embedded Port Status ==<br />
<br />
* best support is available in the git main branch version<br />
* compilers are working, register definitions are available, but libs for peripheral access are rare to non-existent. Hardware can be accessed via hardware registers.<br />
* Not all microcontrollers of each family are supported. If you're interested in support for further microcontrollers, please subscribe to the [http://lists.freepascal.org/mailman/listinfo/fpc-devel fpc-devel mailing list] and write a mail so adding the support can be discussed.<br />
<br />
==How to use heap==<br />
By default, heap is not initialized on embedded targets, so any app trying to allocate on the heap, will crash. To fix that, add the '''heapmgr''' unit to the "uses" clause.<br />
<br />
The size of the heap is controlled with the [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 {$Memory <StackSize>, <HeapSize>}] directive or the -Ch option. Additional regions beside the initial one can be registered using HeapMgr.RegisterHeapBlock.<br />
<br />
== ARM Embedded ==<br />
<br />
=== Build ===<br />
<br />
Get latest FPC from git:<br />
<br />
<syntaxhighlight lang="bash">git clone https://gitlab.com/freepascal.org/fpc/source.git fpc</syntaxhighlight><br />
<br />
Get arm-embedded binutils.<br />
<br />
For windows, they are available at http://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32. You can either checkout the whole directory with or download only arm-embedded-ar.exe, arm-embedded-as.exe, arm-embedded-ld.exe, arm-embedded-strip.exe, arm-embedded-objdump.exe and arm-embedded-objcopy.exe manually. Put these utils in a directory included in your path.<br />
<br />
To build binutils from sources http://wiki.lazarus.freepascal.org/Binutils has instructions, for example, ./configure --target=arm-linux --prefix=/opt/embarm/ --program-prefix=arm-embedded- --disable-werror, has been known to work on binutils 2.21.1 to build the binaries in the form that the fpc target embedded build desires.<br />
<br />
Build FPC for arm-embedded (OABI):<br />
<br />
<syntaxhighlight lang="bash"><br />
cd fpc<br />
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv4<br />
</syntaxhighlight><br />
<br />
This builds only the compiler and the RTL instead of the whole FPC. Because of the limited capabilities of the embedded systems supposed to be used, building all packages is not useful. However, one must be careful to avoid overwriting an existing arm compiler on the system. If this is the case, INSTALL_PREFIX should be used to install into a different directory and switch between those.<br />
<br />
SUBARCH is required and should match your target processor, e.g.:<br />
* for the LPC 21xx parts which are ARM7TDMI (not to be confused with armv7!) based use SUBARCH=armv4<br />
* for cortex-m3 parts (stellaris, stm32, etc) use SUBARCH=armv7m<br />
* for cortex-m devices that support DSP extensions use SUBARCH=armv7em. The compiler does not yet support the cortex-m* FPU<br />
* for cortex-m0 devices use -Cparmv6m<br />
<br />
=== NXP LPC2124 example ===<br />
<br />
Below you find a simple example program for the LPC2124 microcontroller, save it as tled1.pp to follow the description. The program is made for development boards like the LPC-WEB from OLIMEX (http://www.olimex.com/dev/lpc-e2124.html). When you press button 1, led 1 lights for a certain time, same for button 2 and led 2.<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure Wait(d : dword);<br />
begin<br />
while d<>0 do<br />
dec(d);<br />
end;<br />
<br />
begin<br />
{ initialize PLL }<br />
InitPLL(2,1);<br />
<br />
{ initialize LEDs }<br />
{ port 0.8: output }<br />
TBitvector32(GPIO0_IODIR)[8]:=1;<br />
{ port 0.10: output }<br />
TBitvector32(GPIO0_IODIR)[10]:=1;<br />
<br />
{ turn off both LEDs }<br />
TBitvector32(GPIO0_IOSET)[8]:=1;<br />
TBitvector32(GPIO0_IOSET)[10]:=1;<br />
<br />
{ initialize button inputs }<br />
{ port 0.9: input }<br />
TBitvector32(GPIO0_IODIR)[9]:=0;<br />
{ port 0.15: input }<br />
TBitvector32(GPIO0_IODIR)[15]:=0;<br />
<br />
{ endless loop}<br />
while true do<br />
begin<br />
<br />
{ button 1 pressed }<br />
if TBitvector32(GPIO0_IOPIN)[15]=0 then<br />
begin<br />
{ turn on LED, inverse logic }<br />
TBitvector32(GPIO0_IOCLR)[8]:=1;<br />
{ wait }<br />
Wait(500000);<br />
{ turn off LED, inverse logic }<br />
TBitvector32(GPIO0_IOSET)[8]:=1;<br />
end;<br />
<br />
{ button 2 pressed }<br />
if TBitvector32(GPIO0_IOPIN)[9]=0 then<br />
begin<br />
{ turn on LED, inverse logic }<br />
TBitvector32(GPIO0_IOCLR)[10]:=1;<br />
{ wait }<br />
Wait(500000);<br />
{ turn off LED, inverse logic }<br />
TBitvector32(GPIO0_IOSET)[10]:=1;<br />
end;<br />
end;<br />
end.<br />
</syntaxhighlight><br />
<br />
If FPC for arm-embedded is installed as described above, the program can be compiled by<br />
<br />
<syntaxhighlight lang="bash">fpc -Parm -Tembedded -Wplpc2124 tled1.pp</syntaxhighlight><br />
<br />
<syntaxhighlight lang="bash">-Parm</syntaxhighlight><br />
<br />
tells the compiler to compile for arm.<br />
<br />
<syntaxhighlight lang="bash">-Tembedded</syntaxhighlight><br />
<br />
tells the compiler to compile for the embedded target.<br />
<br />
<syntaxhighlight lang="bash">-Wplpc2124</syntaxhighlight><br />
<br />
tells the compiler to compile for the NXP LPC 2124. This has two effects: first, a unit (lpc21x4 in this case) containing the startup code and the port etc. definitions for this controller is loaded. Further, the compiler uses a linker script which fits the needs of this controller.<br />
<br />
The result of the compiler is a .hex file which can be programmed by the NXP flash programming utility.<br />
<br />
When using a board like the mbed (http://mbed.org) which is cortex-m3 based. Another ARM core but uses only thumb/thumb2 instructions not ARM/thumb instructions. A few subtle differences, first building fpc<br />
<br />
<syntaxhighlight lang="bash">make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m</syntaxhighlight><br />
<br />
Second when compiling your program<br />
<br />
<syntaxhighlight lang="bash">fpc -Parm -Tembedded -Wplpc1768 -Cparmv7m myprogram.pp</syntaxhighlight><br />
<br />
The -Cparmv7m option causes thumb2 code to be generated instead of the default (ARM based), probably not a bad idea to use the -Cp for processors using ARM instructions as well. -Wp as with the example above specifies the specific target, in this case microcontroller, to build for.<br />
<br />
=== Nordic nRF51822 example ===<br />
<br />
See the [[micro:bit]] page.<br />
<br />
== Adding new microcontrollers ==<br />
<br />
Adding a new microcontroller type requires basically three steps: first, extend the compiler so it knows about the name of the controller then add a linker script and finally create an RTL unit with the register definitions and the startup code.<br />
<br />
==== Add the microcontroller type to the compiler ====<br />
<br />
This is done in the file <tt>compiler/arm/cpuinfo.pas</tt>. Here you need to add an identifier for the controller in the tcontrollertype enum<br />
At the same time you must update the embedded_controllers array. The array holds information about the amount of flash and sram in the controller, and what rtl unit should be included by default when compiling for that controller.<br />
<br />
''Note: Make sure the string of the two arrays are long enough to contain the strings you write''<br />
<br />
==== Add the linker script to the compiler ====<br />
<br />
Adding a linker script consists of adding the controllertype enum identifier to the case statement in compiler/systems/t_embed.pas If this is not done the compiler will generate an internalerror<br />
<br />
==== Create an RTL unit with startup code and register definitions ====<br />
<br />
Creating an RTL unit means creating a unit that'll automatically be used in a project compiled for the given controller type. This unit should supply an entry point and basic initialization code. Enough to get the controller running<br />
<br />
This unit, which must be named the same as the string written in the controllerunitstr field in the embedded_controllers array, goes into the directory rtl/embedded/arm/ where there are some examples already<br />
<br />
After that the rtl/embedded/Makefile.fpc should be modified, and translated with [[Fpcmake]] so the newly added rtl unit is compiled when building the cross compiler.<br />
The commandline for fpcmake (to be executed in rtl/embedded) is "fpcmake.exe -w -Tall".<br />
<br />
<br />
== AVR ==<br />
<br />
See the [[AVR]] wiki page.<br />
<br />
== MIPSel (PIC32) ==<br />
<br />
See the [[TARGET Embedded Mipsel|MIPSel]] wiki page.<br />
<br />
== Xtensa ==<br />
<br />
See the [[Xtensa]] wiki page.<br />
<br />
== Z80 ==<br />
<br />
See the [[Z80]] wiki page.<br />
<br />
== Useful links ==<br />
<br />
* http://de.wikipedia.org/wiki/Intel_HEX<br />
* http://www.nxp.com/products/microcontrollers/support/software_download/lpc2000/<br />
* http://www.nxp.com/acrobat_download/usermanuals/UM10114_3.pdf<br />
* Jim Lynch: Using Open Source Tools for AT91SAM7 Cross Development - Revision B http://www.atmel.com/dyn/resources/prod_documents/atmel_tutorial_source.zip<br />
<br />
== See Also ==<br />
<br />
* [[Small Virtual Machines#WinXp_virtual_machine]] as have '''simple''' example for Teensy. '''Files released here:''' [[http://turbocontrol.com/simpleteensy.htm]]<br />
<br />
[[Category:Embedded]]<br />
[[Category:Microcontrollers]]<br />
[[Category:FPC]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=154413User Changes Trunk2022-10-08T12:47:46Z<p>PascalDragon: Documented changed default for OpenStrings in mode Delphi</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
==== Open Strings mode enabled by default in mode Delphi ====<br />
* '''Old behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') was not enabled in mode Delphi.<br />
* '''New behaviour:''' The Open Strings feature (directive ''$OpenStrings'' or ''$P'') is enabled in mode Delphi.<br />
* '''Reason:''' Delphi compatibility.<br />
* '''Remedy:''' If you have assembly routines with a ''var'' parameter of type ''ShortString'' then you also need to handle the hidden ''High'' parameter that is added for the Open String or you need to disable Open Strings for that routine.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/188cac3bc6dc666167aacf47fedff1a81d378137 188cac3b]<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068<br />
<br />
==== System - Ref. count of strings ====<br />
<br />
* '''Old behaviour:''' Reference counter of strings was a ''SizeInt''<br />
* '''New behaviour:''' Reference counter of strings is now a ''Longint'' on 64 Bit platforms and ''SizeInt'' on all other platforms.<br />
* '''Reason for change:''' Better alignment of strings<br />
* '''Remedy:''' Call ''System.StringRefCount'' instead of trying to access the ref. count field by pointer operations or other tricks.<br />
* '''git:''' [https://gitlab.com/freepascal.org/fpc/source/-/commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e ee10850a57]<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== Random generator ====<br />
* '''Old behaviour:''' FPC uses a Mersenne twister generate random numbers<br />
* '''New behaviour:''' Now it uses Xoshiro128**<br />
* '''Reason for change:''' Xoshiro128** is faster, has a much smaller memory footprint and generates better random numbers.<br />
* '''Remedy:''' When using a certain randseed, another random sequence is generated, but as the PRNG is considered as an implementation detail, this does not hurt.<br />
* '''git:''' 91cf1774<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField; Later were added also ftSingle and TExtendedField, TSingleField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217, 47219, 47220, 47221; '''git''': c46b45bf<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
==== Sha1 ====<br />
* '''Old behaviour:''' Sha1file silently did nothing on file not found.<br />
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.<br />
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.<br />
* '''svn''': 49166<br />
<br />
==== Image ====<br />
===== FreeType: include bearings and invisible characters into text bounds =====<br />
* '''Old behaviour:''' When the bounds rect was calculated for a text, invisible characters (spaces) and character bearings (spacing around character) were ignored. The result of Canvas.TextExtent() was too short and did not include all with Canvas.TextOut() painted pixels.<br />
* '''New behaviour:''' the bounds rect includes invisible characters and bearings. Canvas.TextExtent() covers the Canvas.TextOut() area.<br />
* '''Reason for change:''' The text could not be correctly aligned to center or right, the underline and textrect fill could not be correctly painted.<br />
* '''svn''': 49629<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Template:Object_Types&diff=153924Template:Object Types2022-08-22T07:51:21Z<p>PascalDragon: Global operators are available for all types</p>
<hr />
<div>{| class="wikitable" <br />
|-<br />
! Feature<br />
! [[Record]]<br />
! [[Record#Advanced_record|Adv Record]]<br />
! [[Object]]<br />
! [[Class]]<br />
|-<br />
| Encapsulation (combining data and methods + hiding visibility)<br />
| No<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| [[Inherited|Inheritance]]<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
|-<br />
| Class constructor and destructor<br />
| No<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Polymorphism (virtual methods)<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
|-<br />
| Memory allocation<br />
| Stack <br />
| Stack<br />
| Stack <br />
| Heap (Only)<br />
|-<br />
|<br />
:Setting fields to zero on allocation<br />
| Managed Types only<br />
| Managed Types only<br />
| Managed Types only<br />
| All fields<br />
|-<br />
|<br />
:Default() function returns a constant with<br />
| all fields zeros<br />
| all fields zeros<br />
| all fields zeros<br />
| returns nil <br />
|-<br />
| Operator overload (global)<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Operator overload (in type only)<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
| Type helpers<br />
| No<br />
| Yes<br />
| No<br />
| Yes<br />
|-<br />
| Virtual constructors, class reference<br />
| No<br />
| No<br />
| No<br />
| Yes<br />
|-<br />
| Variant part (case) as c/c++ union<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
|-<br />
| Bitpacked (really packing)<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
|}<br />
<br />
Modified from [https://forum.lazarus.freepascal.org/index.php/topic,30686.30.html https://forum.lazarus.freepascal.org/index.php/topic,30686.30.html] (original author: ASerge).</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Extended_Pascal&diff=152299Extended Pascal2022-06-07T11:48:57Z<p>PascalDragon: Clarify that the two file approach is merely a suggestion</p>
<hr />
<div>'''Extended Pascal''' is the name given to the version of Pascal specified in International Organization for Standardization (ISO) standard 10206. It specifies an enhanced version of the [[Standard Pascal]] language that was specified in the ISO 7185 specification. The 214-page ISO 10206 document was published in May 1991 and not been revised since.<br />
<br />
Support in Free Pascal for Extended Pascal is planned, and will be via [[Mode extendedpascal|compiler mode <syntaxhighlight lang="pascal" enclose="none">extendedPascal</syntaxhighlight>]].<br />
<br />
== Enhancements to Standard Pascal ==<br />
* Modularity and separate compilation (implemented with new keywords '''module''', '''import''', '''export''', '''only''', '''qualified''' and '''protected''').<br />
* Direct access file handing (via '''SeekRead''', '''SeekWrite''', '''SeekUpdate''' and '''update''' procedures, and the '''position''', '''LastPosition''' and '''empty''' functions as well as an ''update file mode''). <br />
* The procedure '''extend''' prepares an existing file for appending data<br />
* The declaration parts of a program (labels, constants, types, variables, procedures, and functions) can appear in any order<br />
* Complex numbers<br />
<br />
== Reserved Words ==<br />
In addition to all the [[Standard Pascal#Reserved Words|reserved words of Standard Pascal]] the following (referred to as ''word-symbols'' in the ISO 10206 document) have been added to Extended Pascal:<br />
<br />
* and_then (short circuit version of "and"; right side not evaluated if not necessary)<br />
* bindable<br />
* export <br />
* import<br />
* module<br />
* only<br />
* or_else (short circuit version of "or"; right side not evaluated if not necessary)<br />
* otherwise (used with the '''case''' statement and ''variant records'')<br />
* pow (exponentiation for integer, real and complex numbers to real and integer powers)<br />
* protected<br />
* qualified<br />
* restricted<br />
* value<br />
<br />
== Symbols ==<br />
In addition to all the [[Standard_Pascal#Symbols | symbols of Standard Pascal]] the following have been added to Extended Pascal:<br />
<br />
* ** (exponentiation for integer, real and complex numbers to real and integer powers)<br />
* >< (computes a set symmetric difference)<br />
* =><br />
<br />
== Free Pascal support for Extended Pascal ==<br />
Free Pascal has traditionally only supported the Borland dialects of Pascal, but Extended Pascal support will be available via [[Compiler Mode|compiler mode]] [[Mode extendedpascal|extendedpascal]]. [https://bugs.freepascal.org/view.php?id=32549 Bug 0032549] has been set up to track its progress. Below is a list of things that have been implemented (if only in unapplied patches) and things that are planned. The planned features are subject to change.<br />
<br />
=== Already supported features ===<br />
<br />
These features are already supported in Free Pascal 3.0 and some earlier versions.<br />
* The declaration parts of a program (labels, constants, types, variables, procedures, and functions) can appear in any order<br />
* The '''ReadStr''' and '''WriteStr''' procedures.<br />
* The '''Halt''' procedure.<br />
* The '''otherwise''' clause of case statements.<br />
* The [[for-in_loop|'''for''' ... '''in''']] loop<br />
* Array and string slices (mostly working, though assigning to them doesn't).<br />
* The * and >< operators of sets.<br />
* The ** operator (requires the Math unit)<br />
* Various features from ISO 7185 not supported in the Borland dialects (requires ISO mode)<br />
<br />
=== Conformant arrays (not yet implemented) ===<br />
<br />
This is the standard way to pass arrays of various sizes to routines.<br />
<br />
=== Set improvements (not yet implemented) ===<br />
<br />
In addition to the * and >< operators, ISO 10206 also has a '''Card''' function, for retrieving the number of elements in a set. In Free Pascal, sets will still be limited to 256 elements for the foreseeable future (see [https://freepascal.org/future.var Future Plans]).<br />
<br />
=== Generalized ordinal functions (not yet implemeted) ===<br />
<br />
* '''Succ''' and '''Pred''' can take a second argument, making them essentially equivalent to Borland's '''Inc''' and '''Dec'''.<br />
<br />
=== Modules (not yet implemented) ===<br />
<br />
Modules are the standard way for modular programs, covering the same domain as UCSD units. There are two types of modules: those written in a single file and those written in two files. For modules written in one file, Free Pascal will search for them as it does for units (''modulename''.{p,pp,pas}). Suggestion for those written in two files as this is not provided in the standard: the compiler will search for the implementation file normally and then search for ''modulename''.imp.{p,pp,pas}. The interface is in ''modulename''.int.{p,pp,pas}, unless otherwise specified by a {$INTERFACE} directive.<br />
<br />
* The '''import''' section specifies modules to import (much like UCSD's '''uses''') and can be used with the keywords '''only''' (to only import certain identifiers (functions, procedures, types, variables, constants)), and '''qualified''' (qualified identifiers; that is, ''modulename''.''identifier'', rather than just ''identifier''). Identifiers can be renamed on import. An example:<br />
<source lang="pascal"><br />
program PathTest;<br />
<br />
import<br />
SysUtils qualified only (GetEnvironmentVariable => GetEnv);<br />
<br />
begin<br />
WriteLn(SysUtils.GetEnv('PATH'));<br />
end.</source><br />
<br />
* Modules must export identifers for them to be usable to programs or other modules.<br />
* On export, identifers can also be renamed and the '''protected''' keyword can be specified so that other programs and modules can't change the variable's value.<br />
* In the module, the '''restricted''' keyword can be used to make opaque types. To use the example given in the standard:<br />
<source lang="pascal">type<br />
real_widget = record<br />
f1: integer;<br />
f2: real<br />
end;<br />
widget = restricted real_widget;<br />
</source><br />
* The '''to begin do''' statement specifies what happens when the module loads (equivalent to Delphi's '''initialization''' section).<br />
* The '''to end do''' statement specifies what happens when the module unloads (equivalent to Delphi's '''finalization''' section). The example in the standard uses '''to begin do''' to bind a text file on module load, writes to the text file during runtime, and then closes the text file in '''to end do'''.<br />
<br />
Two extensions from [[GNU Pascal]] are also planned:<br />
* The '''all''' keyword to export all identifers from a module's interface (specified identifers can be renamed).<br />
* PXSC (Pascal eXtended for Scientific Computing)-style modules, which are essentially implementation modules without an interface part. (Free Pascal already supports PXSC-style operator overloading, as does GNU Pascal.)<br />
<br />
==== Required interfaces ====<br />
<br />
The modules '''StandardInput''' and '''StandardOutput''' are equivalent to '''input''' and '''output''' in a program's header.<br />
<br />
=== Schemata (not yet implemented) ===<br />
The standard defines a schema as a collection of similar types. Essentially, though, a schema is a data type that takes one or more arguments (called discriminants).<br />
<br />
* The ISO 10206 string type is a schema type.<br />
* The '''New''' procedure can be used to set a schema's discriminants at runtime.<br />
* The '''New''' procedure can also be used to set a variant record's discriminant.<br />
<br />
=== File routines ===<br />
<br />
* The '''bindable''' keyword allows the binding of a variable to an external resource (not implemented, and it might stay that way; GNU Pascal also doesn't allow binding non-files)<br />
* Indexed files (not yet implemented)<br />
* The '''Bind''' procedure to bind a variable to an external resource<br />
* '''Unbind'''<br />
* '''Binding''' returns a '''BindingType''' record, whose Bound field tells if the file was successfully bound<br />
* '''Empty'''<br />
* '''Extend'''<br />
* '''SeekRead'''<br />
* '''SeekWrite'''<br />
* '''SeekUpdate'''<br />
* '''Update'''<br />
* '''Position'''<br />
* '''LastPosition''' (currently, it always returns 0, as its functioning requires support of indexed files)<br />
<br />
=== Date/Time ===<br />
<br />
The '''GetTimeStamp''' procedure fills a '''TimeStamp''' record with details about the current time, which can be converted to a human-readable format via the '''Date''' and '''Time''' functions.<br />
<br />
=== String functions ===<br />
<br />
* '''Substr''', equivalent to '''Copy'''.<br />
* '''Index''', equivalent to '''Pos'''.<br />
* '''Trim'''.<br />
* String comparison through '''EQ''', '''NE''', '''LT''', '''GT''', '''LE''', and '''GE''' (equal to, not equal to, less than, greater than, less than or equal to, greater than or equal to).<br />
<br />
=== Complex Numbers ===<br />
<br />
* There's a '''complex''' data type. In Free Pascal, it's implemented as a record with two fields, but you shouldn't count on that. Instead use the '''Re''' and '''Im''' functions to get the real and imaginary parts, respectively.<br />
* Use '''Cmplx''' to create a complex number from Cartesian arguments or '''Polar''' to create one from polar arguments.<br />
* The standard operators and functions ('''abs''', '''arctan''', '''cos''', '''exp''', '''ln''', '''sin''', '''sqr''', and '''sqrt''') are overloaded to take complex arguments.<br />
* The function '''arg''' gets the complex number's argument.<br />
<br />
=== Number bases (not yet implemented) ===<br />
<br />
It's possible to use any number base from 2 to 36.<br />
<br />
=== Exponents ===<br />
<br />
The ** operator for real exponents has existed in Free Pascal for a while, but the '''pow''' operator for integer exponents remains unimplemented.<br />
<br />
=== New constants ===<br />
<br />
* '''maxchar''' - The highest codepoint supported by a Pascal implementation.<br />
* '''minreal''' - The minimum real value supported.<br />
* '''maxreal''' - The maximum real value supported.<br />
* '''epsreal''' - The precision of reals.<br />
<br />
=== Ensuring the proper order of Boolean expressions (not yet implemented) ===<br />
<br />
ISO 10206 introduces the '''and_then''' and '''or_else''' operators when you need your expression to evaluated left to right. The '''and''' and '''or''' operators, on the other hand, can evaluate the Boolean expressions in any order. These new operators are especially useful for pointer operations, where you need to know whether a pointer is assigned before trying to dereference it.<br />
<br />
=== The value keyword (not yet implemented) ===<br />
<br />
The '''value''' keyword specifies the default value for a variable, type, parameter, or record field.<br />
* For variables and default parameters, this is equivalent to the Delphi operator =.<br />
* For record fields and types, there's no direct equivalent in the Borland dialects, but the [[management operators#Initialize|<syntaxhighlight lang="delphi" inline>initialize</syntaxhighlight> “management operator”]] could perform the same task.<br />
<br />
Note: Default parameters aren't defined in ISO 10206, but are in Appendix C.4 of the [[Object-Oriented Extensions to Pascal|OOE]] draft.<br />
<br />
=== Function result variables (not yet implemented) ===<br />
<br />
Allows to bind a function's result to a variable, sort of like Delphi's '''Result'''.<br />
<br />
=== Protected parameters (not yet implemented) ===<br />
<br />
The '''protected''' keyword can also be used with parameters to indicated that they can't be changed in the routine, giving the compiler hints to aid optimization. To use the example given in the standard:<br />
<source lang="pascal">procedure illustrate(a: integer; var b: integer; protected c: integer; protected var d: integer);<br />
begin<br />
a := 1; { value param }<br />
b := 1; { variable param }<br />
{ c := 1; not legal }<br />
{ d := 1; not legal }<br />
end;</source><br />
<br />
=== Type inquiry (not yet implemented) ===<br />
<br />
Allows you to make the type of one variable or parameter the same as another variable or parameter.<br />
<br />
=== Value constructors (not yet implemented) ===<br />
<br />
This provides a cleaner alternative to Borland's typed constants (which aren't really constants at all) and gives a shortcut to constructing arrays and records at runtime.<br />
<br />
=== Local variables with dynamic size (not yet implemented) ===<br />
<br />
This should work but doesn't currently:<br />
<source lang="pascal">procedure p(n: integer);<br />
var<br />
v: 1..n;<br />
begin<br />
...<br />
end;<br />
</source><br />
<br />
=== Acceptable Identifiers (not yet implemented) ===<br />
* An underscore (<syntaxhighlight lang="pascal" inline>_</syntaxhighlight>) may neither begin or end an identifier.<br />
* Two underscores may not appear in succession, thus <syntaxhighlight lang="pascal" inline>Foo__bar</syntaxhighlight> (''two'' underscores) is illegal.<br />
* Merely all-numeric [[Label|<syntaxhighlight lang="pascal" inline>label</syntaxhighlight>s]] are allowed and have a maximum length of four digits.<br />
<br />
== External links ==<br />
* [http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=18237 ISO/IEC 10206:1991], [http://www.pascal-central.com/docs/iso10206.pdf PDF]: Extended Pascal standard<br />
<br />
<br />
<br />
<br />
[[Category:Pascal]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=$include/de&diff=151658$include/de2022-04-09T13:18:11Z<p>PascalDragon: Schalter -> Bezeichner</p>
<hr />
<div>{{$include}}<br />
<br />
== $I oder $INCLUDE ==<br />
Die Direktive $INCLUDE oder $I dient dem Einfügen einer Datei.<br><br />
Die Direktive $INCLUDE oder $I fügt an der Stelle an der die Anweisung steht eine Datei ein.<br><br />
Falls die einzufügende Datei keine Dateiendung hat, dann sucht der Compiler nach einer Datei mit der Endung .pp.<br><br />
Die Anzahl der einzufügenden Dateien ist auf die Anzahl der verfügbaren file descriptors des Free Pascal Compilers beschränkt.<br><br />
<br><br />
Beispiel:<br><br />
<syntaxhighlight lang="pascal"><br />
{$INCLUDE test1.pas} // sucht im aktuellen Verzeichnis nach der Datei test1.pas<br />
{$INCLUDE ../test2.pas} // sucht im übergeordneten Verzeichnis nach der Datei test2.pas<br />
</syntaxhighlight><br />
<br />
<br />
== $I und $INCLUDE ==<br />
Die Direktiven $I und $INCLUDE haben die gleiche Bedeutung.<br><br />
Die Direktiven $I und $INCLUDE unterstützen die gleichen Bezeichner.<br><br />
<br><br />
Die Direktiven kennen folgende Bezeichner:<br><br />
<table><br />
<tr><br />
<td>TIME</td><td>Gibt das aktuelle Datum und die aktuelle Zeit aus.</td><br />
</tr><br />
<tr><br />
<td>DATE</td><td>Fügt das aktuelle Datum ein.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGET</td><td>Fügt den Namen des Zielprozessors ein. Dieser Bezeichner ist deprecated (hinfällig). Der neue Bezeichner heisst FPCTARGETCPU.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGETCPU </td><td>Fügt den Namen des Zielprozessors ein.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGETOS</td><td>Fügt den Namen des Zielbetriebsystems ein.</td><br />
</tr><br />
<tr><br />
<td>FPCVERSION</td><td>Fügt die aktuelle Compilerversion ein.</td><br />
</tr><br />
<tr><br />
<td>FILE</td><td>Dateiname, in der die Direktive steht.</td><br />
</tr><br />
<tr><br />
<td>LINE</td><td>Nummer der Zeile, in der die Direktive steht.</td><br />
</tr><br />
<tr><br />
<td>CURRENTROUTINE</td><td>Name der aktuellen Routine.</td><br />
</tr><br />
</table><br />
Andere Bezeichner werden aus den Umgebungsvariablen des Compiler Prozesses genommen.<br />
<br><br />
Beispiel:<br />
<syntaxhighlight lang="pascal"><br />
Program InfoDemo;<br />
begin<br />
WriteLn('Compilierzeit: ' + {$I %TIME%});<br />
WriteLn('Compilierdatum: ' + {$I %DATE%});<br />
WriteLn('Erforderliche CPU: ' + {$I %FPCTARGETCPU%});<br />
WriteLn('Erforderliche CPU (veraltet): ' + {$I %FPCTARGET%});<br />
WriteLn('Betriebssystem: ' + {$I %FPCTARGETOS%});<br />
WriteLn('FPC Version: ' + {$I %FPCVERSION%});<br />
WriteLn('Name der Datei: ' + {$I %FILE%});<br />
WriteLn('Aktuelle Zeile als String: ' + {$I %LINE%});<br />
WriteLn('Aktuelle Zeile als Int: ' + IntToStr({$I %LINENUM%}));<br />
WriteLn('Compilierer: ' + {$I %USER%});<br />
WriteLn('Home-Ordner des Benutzers: ' + {$I %HOME%});<br />
WriteLn('Name der aktuellen Routine: ' + {$I %CURRENTROUTINE%});<br />
end.<br />
</syntaxhighlight><br />
<br><br />
<br><br />
Hinweis: Für Infos über Lazarus, kann die Unit <b>LCLVersion</b> eingebunden werden.</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=$include/de&diff=151657$include/de2022-04-09T13:17:29Z<p>PascalDragon: USER und HOME sind keine Standardbezeichner, die FPC unterstützt</p>
<hr />
<div>{{$include}}<br />
<br />
== $I oder $INCLUDE ==<br />
Die Direktive $INCLUDE oder $I dient dem Einfügen einer Datei.<br><br />
Die Direktive $INCLUDE oder $I fügt an der Stelle an der die Anweisung steht eine Datei ein.<br><br />
Falls die einzufügende Datei keine Dateiendung hat, dann sucht der Compiler nach einer Datei mit der Endung .pp.<br><br />
Die Anzahl der einzufügenden Dateien ist auf die Anzahl der verfügbaren file descriptors des Free Pascal Compilers beschränkt.<br><br />
<br><br />
Beispiel:<br><br />
<syntaxhighlight lang="pascal"><br />
{$INCLUDE test1.pas} // sucht im aktuellen Verzeichnis nach der Datei test1.pas<br />
{$INCLUDE ../test2.pas} // sucht im übergeordneten Verzeichnis nach der Datei test2.pas<br />
</syntaxhighlight><br />
<br />
<br />
== $I und $INCLUDE ==<br />
Die Direktiven $I und $INCLUDE haben die gleiche Bedeutung.<br><br />
Die Direktiven $I und $INCLUDE haben die gleichen Schalter.<br><br />
<br><br />
Die Direktiven kennen folgende Schalter:<br><br />
<table><br />
<tr><br />
<td>TIME</td><td>Gibt das aktuelle Datum und die aktuelle Zeit aus.</td><br />
</tr><br />
<tr><br />
<td>DATE</td><td>Fügt das aktuelle Datum ein.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGET</td><td>Fügt den Namen des Zielprozessors ein. Dieser Schalter ist deprecated (hinfällig). Der neue Schalter heisst FPCTARGETCPU.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGETCPU </td><td>Fügt den Namen des Zielprozessors ein.</td><br />
</tr><br />
<tr><br />
<td>FPCTARGETOS</td><td>Fügt den Namen des Zielbetriebsystems ein.</td><br />
</tr><br />
<tr><br />
<td>FPCVERSION</td><td>Fügt die aktuelle Compilerversion ein.</td><br />
</tr><br />
<tr><br />
<td>FILE</td><td>Dateiname, in der die Direktive steht.</td><br />
</tr><br />
<tr><br />
<td>LINE</td><td>Nummer der Zeile, in der die Direktive steht.</td><br />
</tr><br />
<tr><br />
<td>CURRENTROUTINE</td><td>Name der aktuellen Routine.</td><br />
</tr><br />
</table><br />
Andere Bezeichner werden aus den Umgebungsvariablen des Compiler Prozesses genommen.<br />
<br><br />
Beispiel:<br />
<syntaxhighlight lang="pascal"><br />
Program InfoDemo;<br />
begin<br />
WriteLn('Compilierzeit: ' + {$I %TIME%});<br />
WriteLn('Compilierdatum: ' + {$I %DATE%});<br />
WriteLn('Erforderliche CPU: ' + {$I %FPCTARGETCPU%});<br />
WriteLn('Erforderliche CPU (veraltet): ' + {$I %FPCTARGET%});<br />
WriteLn('Betriebssystem: ' + {$I %FPCTARGETOS%});<br />
WriteLn('FPC Version: ' + {$I %FPCVERSION%});<br />
WriteLn('Name der Datei: ' + {$I %FILE%});<br />
WriteLn('Aktuelle Zeile als String: ' + {$I %LINE%});<br />
WriteLn('Aktuelle Zeile als Int: ' + IntToStr({$I %LINENUM%}));<br />
WriteLn('Compilierer: ' + {$I %USER%});<br />
WriteLn('Home-Ordner des Benutzers: ' + {$I %HOME%});<br />
WriteLn('Name der aktuellen Routine: ' + {$I %CURRENTROUTINE%});<br />
end.<br />
</syntaxhighlight><br />
<br><br />
<br><br />
Hinweis: Für Infos über Lazarus, kann die Unit <b>LCLVersion</b> eingebunden werden.</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User:PascalDragon&diff=150806User:PascalDragon2022-02-19T22:49:52Z<p>PascalDragon: Updated links to mailing list threads</p>
<hr />
<div>Hi! My name is Sven, I'm a Free Pascal user and core developer from Germany and these are my current FPC/Lazarus related projects:<br />
<br />
===ports===<br />
*[[Target_NativeNT|Native NT]]: This port allows to write early user space applications, sub systems and device drivers for Windows NT based systems (NT, 2000, XP, 2003, Vista, 2008, 7).<br />
:State: Base RTL works nearly completely <br />
:next steps:<br />
:*enable process execution, threading and utilize NT's exception handling<br />
:*test the compiler on Native NT<br />
:*get units ''crt'', ''keyboard'', ''video'', ''graph'' working<br />
:*get all Pascal only units in ''packages'' working<br />
:*get the textmode IDE working<br />
*MINIX: [http://www.minix3.org/ MINIX] is a Unix-like operating system that is based on top of a microkernel originately developed by Andrew S. Tanenbaum. All device drivers are running in usermode and communicate using IPC.<br />
:State: working on implementation in compiler<br />
<br />
===current projects===<br />
*Improvements for generics: Generics still are either not as bug free as wished or don't support specific features like generic methods/functions/procedures.<br />
*[http://wayland.freedesktop.org/ Wayland] units: Convert the Wayland headers so clients for this new display server can be written in Pascal. This should provide the basis for a CustomDrawn-Wayland widgetset<br />
<br />
===planned projects (no particular order)===<br />
*Support for Attributes (this is being worked on by Joost) and extended RTTI introduced with Delphi 2009<br />
*Support for anonymous functions<br />
*Support for runtime packages<br />
*Add "WinRT" (aka Metro) target<br />
*Add fpmake support for utils, compiler and RTL<br />
*Improve the RTL/FCL:<br />
**add TMonitor support<br />
**bring SyncObjs up to par with Delphi XE3 (possibly with various spin lock algorithms)<br />
**add generic Collection [List, Queue, Stack] interfaces and classes (possibly compatible with Delphi XE3)<br />
**add a "Random" unit with an IRandom interface and various Random implementations<br />
**add a cross plattform unit for SIMD operations<br />
**maybe add support for higher order functions (map, filter, fold) in standard classes/interfaces<br />
**further improvements in other units<br />
**further additions of other units<br />
*Add compiler/RTL provided profiling system (callback called on each ''begin'' and ''end'')<br />
*Add support for "as" and "is" to CORBA interfaces<br />
*Support for contracts (ensure, require, invariants) introduced by Oxygene (Delphi Prism)<br />
*Maybe implement an oxygene syntax mode<br />
*Add operators for "EntersScope" and "LeavesScope"<br />
*Support for native linking with C++ classes (aka finish the ''cppclass'' concept)<br />
*Explore additional language concepts like [http://en.wikipedia.org/wiki/Trait_%28computer_science%29 Traits], [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming], [http://en.wikipedia.org/wiki/Type_inference Type Inference] and [http://en.wikipedia.org/wiki/Duck_typing Duck Typing]<br />
<br />
===past projects===<br />
*External thread variables collector for Windows: This is needed for Windows systems (Win32, Win64, WinCE) to allow the initialization of the RTL for external threads. External threads are threads that are not created by BeginThread (TThread uses BeginThread). Although work is underway to implement Thread Local Storage in FPC, the collector will be needed for older systems (Win9x) and maybe WinCE as those don't implement Thread Local Storage.<br />
:See also [http://bugs.freepascal.org/view.php?id=17300 this] bug report<br />
:State: nearly done<br />
*[[Helper types|Class/record helpers]]: Delphi 2006 (or even 2005) introduced so called class and record helpers which allow to extend the scope the compiler uses when searching for symbols (methods primarily).<br />
:The work is done in a [http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/svenbarth/classhelpers/ branch]<br />
:State: Some examples are working, but I run into a dead end and need to completely rework my implementation (which is nearly done, so normal development can continue)<br />
*Type helpers: Delphi XE3 introduced support for helper types for primitive types. Support for these was added to FPC as well.<br />
:See also [http://lists.freepascal.org/pipermail/fpc-announce/2013-February/000587.html this] announcement e-mail<br />
*Extension of TThread class: Newer Delphi versions added further methods to TThread like Queue. In December 2012 the TThread class was brought up to par with Delphi XE3.<br />
:See also [http://lists.freepascal.org/pipermail/fpc-devel/2012-December/030841.html this] announcement e-mail<br />
*Generic constraints: Generic constraints allow to state an restriction for the types that can be used to specialize a generic.<br />
:See also [http://lists.freepascal.org/pipermail/fpc-announce/2012-December/000586.html this] announcement e-mail</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=150805FPC New Features Trunk2022-02-19T22:11:27Z<p>PascalDragon: Swapped order of commit and example</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Array constructors for static arrays ====<br />
* '''Overview''': Array constructors can be used to assign values to static arrays.<br />
* '''Notes''':<br />
** The array constructor needs to have the same amount of elements as the static array.<br />
** The first element of the array constructor will be placed at the location of the first element of the static array (e.g. if the array starts at -1 the first element will be at that location).<br />
** Arrays with enumeration index are supported as well.<br />
* '''svn''': 46891, 46901<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tarrconstr16.pp<br />
<br />
==== "Align" modifier support for record definitions ====<br />
* '''Overview''': It is now possible to add an '''Align X''' modifier at the end of a record definition to indicate that the record as a whole should be aligned to a particular boundary.<br />
* '''Notes''':<br />
** Should be Delphi compatible, although documentation is not available ([https://web.archive.org/web/20171221044023/http://qc.embarcadero.com/wc/qcmain.aspx?d=87283 "semi-official" reference]; the mentioned issue does not exist in the FPC implementation).<br />
** This does not influence the alignment of the individual fields, which are still aligned according to the current ''{$packrecords y}''/''{$align y}'' settings.<br />
** X can be 1, 2, 4, 8, 32 or 64.<br />
* '''svn''': 47892<br />
* '''Example''': https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw28927.pp?view=markup&pathrev=47892<br />
<br />
==== Support for binary literals in Delphi mode ====<br />
* '''Overview''': It is now possible to use binary literals ('%' as prefix) in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39503 #39503]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
b: byte;<br />
begin<br />
b:=%11001001;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for Digit Separator ====<br />
* '''Overview''': It is now possible to use the Digit Separator ('_') with the ''underscoreisseparator'' modeswitch. It is also enabled by default in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39504 #39504]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
i: Integer;<br />
r: Real;<br />
begin<br />
i := %1001_1001;<br />
i := &121_102;<br />
i := 1_123_123;<br />
i := $1_123_123; <br />
r := 1_123_123.000_000;<br />
r := 1_123_123.000_000e1_2;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for forward declarations of generic types ====<br />
* '''Overview''': It is now possible to use forward declarations for generic classes and interfaces like is possible for non-generic classes and interfaces.<br />
* '''Notes''':<br />
** Generic type constraints and const declarations need to be used for both the forward and the final implementation like is necessary for global generic routines.<br />
** This is Delphi-compatible.<br />
* '''Commit''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/2a5023508a2bc4ff3ba4f3a0ca16366d3df86db8 2a502350]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
generic TTest<T> = class;<br />
generic TFoo<T: class> = class;<br />
generic TBar<const N: LongInt> = class;<br />
<br />
TSomething = class<br />
fTest: specialize TTest<LongInt>;<br />
fFoo: specialize TFoo<TObject>;<br />
fBar: specialize TBar<42>;<br />
end;<br />
<br />
generic TTest<T> = class end;<br />
generic TFoo<T: class> = class end;<br />
generic TBar<const N: LongInt> = class end;<br />
<br />
begin<br />
end.<br />
</syntaxhighlight><br />
<br />
=== Units ===<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the user changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented for macOS.<br />
* '''Notes''': Delphi compatible, was already implemented for Windows, Linux and Android and finally for macOS now. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 49323<br />
<br />
==== Objects ====<br />
===== TRawByteStringCollection =====<br />
* '''Overview''': A new object type TRawByteStringCollection, similar to TStringCollection, but works with RawByteString/AnsiString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TUnicodeStringCollection =====<br />
* '''Overview''': A new object type TUnicodeStringCollection, similar to TStringCollection, but works with UnicodeString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TStream methods for reading and writing RawByteString and UnicodeString =====<br />
* '''Overview''': New methods have been added to TStream for reading and writing RawByteString/AnsiString and UnicodeString types.<br />
* '''Notes''': The following methods have been added:<br />
FUNCTION TStream.ReadRawByteString: RawByteString;<br />
FUNCTION TStream.ReadUnicodeString: UnicodeString;<br />
PROCEDURE TStream.WriteRawByteString (Const S: RawByteString);<br />
PROCEDURE TStream.WriteUnicodeString (Const S: UnicodeString);<br />
RawByteStrings are written to the stream as a 16-bit code page, followed by 32-bit length, followed by the string contents. UnicodeStrings are written as a 32-bit length (the number of 16-bit UTF-16 code units needed to encode the string), followed by the string itself in UTF-16.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Free Vision ====<br />
===== Unicode support =====<br />
* '''Overview''': Unicode versions of the Free Vision units have been added.<br />
* '''Notes''': The Unicode versions of the units have the same name as their non-Unicode counterparts, but with an added 'U' prefix in the beginning of their name. For example, the Unicode version of the 'app' unit is 'uapp', the Unicode version of 'views' is 'uviews', etc. The Unicode versions of the units use the UnicodeString type, instead of shortstrings and pchars. Mixing Unicode and non-Unicode Free Vision units in the same program is not supported and will not work.<br />
* '''More information''': [[Free_Vision#Unicode_version]]<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Video ====<br />
===== Unicode output support =====<br />
* '''Overview''': Unicode video buffer support has been added to the Video unit.<br />
* '''Notes''': To use the Unicode video buffer, you must call InitEnhancedVideo instead of InitVideo and finalize the unit with DoneEnhancedVideo instead of DoneVideo. After initializing with InitEnhancedVideo, you must use the EnhancedVideoBuf array instead of VideoBuf. On non-Unicode operating systems, the Video unit will automatically translate Unicode characters to the console code page. This is done transparently to the user application, so new programs can always use EnhancedVideoBuf, without worrying about compatibility.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Keyboard ====<br />
===== Unicode keyboard input support =====<br />
* '''Overview''': Unicode keyboard input support has been added to the Keyboard unit.<br />
* '''Notes''': After initializing the unit normally via InitKeyboard, you can obtain enhanced key events, which include Unicode character information, as well as an enhanced shift state. To get enhanced key events, use GetEnhancedKeyEvent or PollEnhancedKeyEvent. They return a TEnhancedKeyEvent, which is a record with these fields:<br />
TEnhancedKeyEvent = record<br />
VirtualKeyCode: Word; { device-independent identifier of the key }<br />
VirtualScanCode: Word; { device-dependent value, generated by the keyboard }<br />
UnicodeChar: WideChar; { the translated Unicode character }<br />
AsciiChar: Char; { the translated ASCII character }<br />
ShiftState: TEnhancedShiftState;<br />
Flags: Byte;<br />
end;<br />
<br />
TEnhancedShiftState is a set of TEnhancedShiftStateElement, which is defined as:<br />
TEnhancedShiftStateElement = (<br />
essShift, { either Left or Right Shift is pressed }<br />
essLeftShift,<br />
essRightShift,<br />
essCtrl, { either Left or Right Ctrl is pressed }<br />
essLeftCtrl,<br />
essRightCtrl,<br />
essAlt, { either Left or Right Alt is pressed, but *not* AltGr }<br />
essLeftAlt,<br />
essRightAlt, { only on keyboard layouts, without AltGr }<br />
essAltGr, { only on keyboard layouts, with AltGr instead of Right Alt }<br />
essCapsLockPressed,<br />
essCapsLockOn,<br />
essNumLockPressed,<br />
essNumLockOn,<br />
essScrollLockPressed,<br />
essScrollLockOn<br />
);<br />
<br />
A special value NilEnhancedKeyEvent is used to indicate no key event available in the result of PollEnhancedKeyEvent:<br />
{ The Nil value for the enhanced key event }<br />
NilEnhancedKeyEvent: TEnhancedKeyEvent = (<br />
VirtualKeyCode: 0;<br />
VirtualScanCode: 0;<br />
UnicodeChar: #0;<br />
AsciiChar: #0;<br />
ShiftState: [];<br />
Flags: 0;<br />
);<br />
<br />
* '''git:''' 0b8a0fb4<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Support for symbolicating Dwarf backtraces ===<br />
* '''Overview''': The -gl option now works with DWARF debug information on Darwin. This is the default for non-PowerPC Darwin targets, and the only support format for ARM and 64 bit Darwin targets.<br />
* '''Notes''': You have to also use the -Xg command line option when compiling the main program or library, to generate a .dSYM bundle that contains all debug information. You can also do this manually by calling ''dsymutil''<br />
* '''svn''': 49140<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Darwin/AArch64 (only macOS; iOS has not been tested), Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for the Z80 ===<br />
* '''Overview''': Support has been added for generating Z80 code.<br />
* '''More information''': [[Z80]]<br />
<br />
=== Support for the WebAssembly target ===<br />
* '''Overview''': Support has been added for generating WebAssembly code.<br />
* '''More information''': [[WebAssembly/Compiler]]<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=150804FPC New Features Trunk2022-02-19T22:10:41Z<p>PascalDragon: Documented forward declarations for generic classes and interfaces</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Array constructors for static arrays ====<br />
* '''Overview''': Array constructors can be used to assign values to static arrays.<br />
* '''Notes''':<br />
** The array constructor needs to have the same amount of elements as the static array.<br />
** The first element of the array constructor will be placed at the location of the first element of the static array (e.g. if the array starts at -1 the first element will be at that location).<br />
** Arrays with enumeration index are supported as well.<br />
* '''svn''': 46891, 46901<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tarrconstr16.pp<br />
<br />
==== "Align" modifier support for record definitions ====<br />
* '''Overview''': It is now possible to add an '''Align X''' modifier at the end of a record definition to indicate that the record as a whole should be aligned to a particular boundary.<br />
* '''Notes''':<br />
** Should be Delphi compatible, although documentation is not available ([https://web.archive.org/web/20171221044023/http://qc.embarcadero.com/wc/qcmain.aspx?d=87283 "semi-official" reference]; the mentioned issue does not exist in the FPC implementation).<br />
** This does not influence the alignment of the individual fields, which are still aligned according to the current ''{$packrecords y}''/''{$align y}'' settings.<br />
** X can be 1, 2, 4, 8, 32 or 64.<br />
* '''svn''': 47892<br />
* '''Example''': https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw28927.pp?view=markup&pathrev=47892<br />
<br />
==== Support for binary literals in Delphi mode ====<br />
* '''Overview''': It is now possible to use binary literals ('%' as prefix) in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39503 #39503]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
b: byte;<br />
begin<br />
b:=%11001001;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for Digit Separator ====<br />
* '''Overview''': It is now possible to use the Digit Separator ('_') with the ''underscoreisseparator'' modeswitch. It is also enabled by default in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39504 #39504]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
i: Integer;<br />
r: Real;<br />
begin<br />
i := %1001_1001;<br />
i := &121_102;<br />
i := 1_123_123;<br />
i := $1_123_123; <br />
r := 1_123_123.000_000;<br />
r := 1_123_123.000_000e1_2;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for forward declarations of generic types ====<br />
* '''Overview''': It is now possible to use forward declarations for generic classes and interfaces like is possible for non-generic classes and interfaces.<br />
* '''Notes''':<br />
** Generic type constraints and const declarations need to be used for both the forward and the final implementation like is necessary for global generic routines.<br />
** This is Delphi-compatible.<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
generic TTest<T> = class;<br />
generic TFoo<T: class> = class;<br />
generic TBar<const N: LongInt> = class;<br />
<br />
TSomething = class<br />
fTest: specialize TTest<LongInt>;<br />
fFoo: specialize TFoo<TObject>;<br />
fBar: specialize TBar<42>;<br />
end;<br />
<br />
generic TTest<T> = class end;<br />
generic TFoo<T: class> = class end;<br />
generic TBar<const N: LongInt> = class end;<br />
<br />
begin<br />
end.<br />
</syntaxhighlight><br />
* '''Commit''': [https://gitlab.com/freepascal.org/fpc/source/-/commit/2a5023508a2bc4ff3ba4f3a0ca16366d3df86db8 2a502350]<br />
<br />
=== Units ===<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the user changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented for macOS.<br />
* '''Notes''': Delphi compatible, was already implemented for Windows, Linux and Android and finally for macOS now. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 49323<br />
<br />
==== Objects ====<br />
===== TRawByteStringCollection =====<br />
* '''Overview''': A new object type TRawByteStringCollection, similar to TStringCollection, but works with RawByteString/AnsiString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TUnicodeStringCollection =====<br />
* '''Overview''': A new object type TUnicodeStringCollection, similar to TStringCollection, but works with UnicodeString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TStream methods for reading and writing RawByteString and UnicodeString =====<br />
* '''Overview''': New methods have been added to TStream for reading and writing RawByteString/AnsiString and UnicodeString types.<br />
* '''Notes''': The following methods have been added:<br />
FUNCTION TStream.ReadRawByteString: RawByteString;<br />
FUNCTION TStream.ReadUnicodeString: UnicodeString;<br />
PROCEDURE TStream.WriteRawByteString (Const S: RawByteString);<br />
PROCEDURE TStream.WriteUnicodeString (Const S: UnicodeString);<br />
RawByteStrings are written to the stream as a 16-bit code page, followed by 32-bit length, followed by the string contents. UnicodeStrings are written as a 32-bit length (the number of 16-bit UTF-16 code units needed to encode the string), followed by the string itself in UTF-16.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Free Vision ====<br />
===== Unicode support =====<br />
* '''Overview''': Unicode versions of the Free Vision units have been added.<br />
* '''Notes''': The Unicode versions of the units have the same name as their non-Unicode counterparts, but with an added 'U' prefix in the beginning of their name. For example, the Unicode version of the 'app' unit is 'uapp', the Unicode version of 'views' is 'uviews', etc. The Unicode versions of the units use the UnicodeString type, instead of shortstrings and pchars. Mixing Unicode and non-Unicode Free Vision units in the same program is not supported and will not work.<br />
* '''More information''': [[Free_Vision#Unicode_version]]<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Video ====<br />
===== Unicode output support =====<br />
* '''Overview''': Unicode video buffer support has been added to the Video unit.<br />
* '''Notes''': To use the Unicode video buffer, you must call InitEnhancedVideo instead of InitVideo and finalize the unit with DoneEnhancedVideo instead of DoneVideo. After initializing with InitEnhancedVideo, you must use the EnhancedVideoBuf array instead of VideoBuf. On non-Unicode operating systems, the Video unit will automatically translate Unicode characters to the console code page. This is done transparently to the user application, so new programs can always use EnhancedVideoBuf, without worrying about compatibility.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Keyboard ====<br />
===== Unicode keyboard input support =====<br />
* '''Overview''': Unicode keyboard input support has been added to the Keyboard unit.<br />
* '''Notes''': After initializing the unit normally via InitKeyboard, you can obtain enhanced key events, which include Unicode character information, as well as an enhanced shift state. To get enhanced key events, use GetEnhancedKeyEvent or PollEnhancedKeyEvent. They return a TEnhancedKeyEvent, which is a record with these fields:<br />
TEnhancedKeyEvent = record<br />
VirtualKeyCode: Word; { device-independent identifier of the key }<br />
VirtualScanCode: Word; { device-dependent value, generated by the keyboard }<br />
UnicodeChar: WideChar; { the translated Unicode character }<br />
AsciiChar: Char; { the translated ASCII character }<br />
ShiftState: TEnhancedShiftState;<br />
Flags: Byte;<br />
end;<br />
<br />
TEnhancedShiftState is a set of TEnhancedShiftStateElement, which is defined as:<br />
TEnhancedShiftStateElement = (<br />
essShift, { either Left or Right Shift is pressed }<br />
essLeftShift,<br />
essRightShift,<br />
essCtrl, { either Left or Right Ctrl is pressed }<br />
essLeftCtrl,<br />
essRightCtrl,<br />
essAlt, { either Left or Right Alt is pressed, but *not* AltGr }<br />
essLeftAlt,<br />
essRightAlt, { only on keyboard layouts, without AltGr }<br />
essAltGr, { only on keyboard layouts, with AltGr instead of Right Alt }<br />
essCapsLockPressed,<br />
essCapsLockOn,<br />
essNumLockPressed,<br />
essNumLockOn,<br />
essScrollLockPressed,<br />
essScrollLockOn<br />
);<br />
<br />
A special value NilEnhancedKeyEvent is used to indicate no key event available in the result of PollEnhancedKeyEvent:<br />
{ The Nil value for the enhanced key event }<br />
NilEnhancedKeyEvent: TEnhancedKeyEvent = (<br />
VirtualKeyCode: 0;<br />
VirtualScanCode: 0;<br />
UnicodeChar: #0;<br />
AsciiChar: #0;<br />
ShiftState: [];<br />
Flags: 0;<br />
);<br />
<br />
* '''git:''' 0b8a0fb4<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Support for symbolicating Dwarf backtraces ===<br />
* '''Overview''': The -gl option now works with DWARF debug information on Darwin. This is the default for non-PowerPC Darwin targets, and the only support format for ARM and 64 bit Darwin targets.<br />
* '''Notes''': You have to also use the -Xg command line option when compiling the main program or library, to generate a .dSYM bundle that contains all debug information. You can also do this manually by calling ''dsymutil''<br />
* '''svn''': 49140<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Darwin/AArch64 (only macOS; iOS has not been tested), Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for the Z80 ===<br />
* '''Overview''': Support has been added for generating Z80 code.<br />
* '''More information''': [[Z80]]<br />
<br />
=== Support for the WebAssembly target ===<br />
* '''Overview''': Support has been added for generating WebAssembly code.<br />
* '''More information''': [[WebAssembly/Compiler]]<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=150803FPC New Features Trunk2022-02-18T19:02:22Z<p>PascalDragon: Fix typo</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Array constructors for static arrays ====<br />
* '''Overview''': Array constructors can be used to assign values to static arrays.<br />
* '''Notes''':<br />
** The array constructor needs to have the same amount of elements as the static array.<br />
** The first element of the array constructor will be placed at the location of the first element of the static array (e.g. if the array starts at -1 the first element will be at that location).<br />
** Arrays with enumeration index are supported as well.<br />
* '''svn''': 46891, 46901<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tarrconstr16.pp<br />
<br />
==== "Align" modifier support for record definitions ====<br />
* '''Overview''': It is now possible to add an '''Align X''' modifier at the end of a record definition to indicate that the record as a whole should be aligned to a particular boundary.<br />
* '''Notes''':<br />
** Should be Delphi compatible, although documentation is not available ([https://web.archive.org/web/20171221044023/http://qc.embarcadero.com/wc/qcmain.aspx?d=87283 "semi-official" reference]; the mentioned issue does not exist in the FPC implementation).<br />
** This does not influence the alignment of the individual fields, which are still aligned according to the current ''{$packrecords y}''/''{$align y}'' settings.<br />
** X can be 1, 2, 4, 8, 32 or 64.<br />
* '''svn''': 47892<br />
* '''Example''': https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw28927.pp?view=markup&pathrev=47892<br />
<br />
==== Support for binary literals in Delphi mode ====<br />
* '''Overview''': It is now possible to use binary literals ('%' as prefix) in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39503 #39503]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
b: byte;<br />
begin<br />
b:=%11001001;<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for Digit Separator ====<br />
* '''Overview''': It is now possible to use the Digit Separator ('_') with the ''underscoreisseparator'' modeswitch. It is also enabled by default in Delphi mode.<br />
* '''Notes''': [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What%27s_New#Binary_Literals_and_Digit_Separator Delphi compatibility].<br />
* '''GitLab issue''': [https://gitlab.com/freepascal.org/fpc/source/-/issues/39504 #39504]<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode Delphi}<br />
var<br />
i: Integer;<br />
r: Real;<br />
begin<br />
i := %1001_1001;<br />
i := &121_102;<br />
i := 1_123_123;<br />
i := $1_123_123; <br />
r := 1_123_123.000_000;<br />
r := 1_123_123.000_000e1_2;<br />
end.<br />
</syntaxhighlight><br />
<br />
=== Units ===<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the user changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented for macOS.<br />
* '''Notes''': Delphi compatible, was already implemented for Windows, Linux and Android and finally for macOS now. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 49323<br />
<br />
==== Objects ====<br />
===== TRawByteStringCollection =====<br />
* '''Overview''': A new object type TRawByteStringCollection, similar to TStringCollection, but works with RawByteString/AnsiString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TUnicodeStringCollection =====<br />
* '''Overview''': A new object type TUnicodeStringCollection, similar to TStringCollection, but works with UnicodeString<br />
* '''git:''' 0b8a0fb4<br />
<br />
===== TStream methods for reading and writing RawByteString and UnicodeString =====<br />
* '''Overview''': New methods have been added to TStream for reading and writing RawByteString/AnsiString and UnicodeString types.<br />
* '''Notes''': The following methods have been added:<br />
FUNCTION TStream.ReadRawByteString: RawByteString;<br />
FUNCTION TStream.ReadUnicodeString: UnicodeString;<br />
PROCEDURE TStream.WriteRawByteString (Const S: RawByteString);<br />
PROCEDURE TStream.WriteUnicodeString (Const S: UnicodeString);<br />
RawByteStrings are written to the stream as a 16-bit code page, followed by 32-bit length, followed by the string contents. UnicodeStrings are written as a 32-bit length (the number of 16-bit UTF-16 code units needed to encode the string), followed by the string itself in UTF-16.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Free Vision ====<br />
===== Unicode support =====<br />
* '''Overview''': Unicode versions of the Free Vision units have been added.<br />
* '''Notes''': The Unicode versions of the units have the same name as their non-Unicode counterparts, but with an added 'U' prefix in the beginning of their name. For example, the Unicode version of the 'app' unit is 'uapp', the Unicode version of 'views' is 'uviews', etc. The Unicode versions of the units use the UnicodeString type, instead of shortstrings and pchars. Mixing Unicode and non-Unicode Free Vision units in the same program is not supported and will not work.<br />
* '''More information''': [[Free_Vision#Unicode_version]]<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Video ====<br />
===== Unicode output support =====<br />
* '''Overview''': Unicode video buffer support has been added to the Video unit.<br />
* '''Notes''': To use the Unicode video buffer, you must call InitEnhancedVideo instead of InitVideo and finalize the unit with DoneEnhancedVideo instead of DoneVideo. After initializing with InitEnhancedVideo, you must use the EnhancedVideoBuf array instead of VideoBuf. On non-Unicode operating systems, the Video unit will automatically translate Unicode characters to the console code page. This is done transparently to the user application, so new programs can always use EnhancedVideoBuf, without worrying about compatibility.<br />
* '''git:''' 0b8a0fb4<br />
<br />
==== Keyboard ====<br />
===== Unicode keyboard input support =====<br />
* '''Overview''': Unicode keyboard input support has been added to the Keyboard unit.<br />
* '''Notes''': After initializing the unit normally via InitKeyboard, you can obtain enhanced key events, which include Unicode character information, as well as an enhanced shift state. To get enhanced key events, use GetEnhancedKeyEvent or PollEnhancedKeyEvent. They return a TEnhancedKeyEvent, which is a record with these fields:<br />
TEnhancedKeyEvent = record<br />
VirtualKeyCode: Word; { device-independent identifier of the key }<br />
VirtualScanCode: Word; { device-dependent value, generated by the keyboard }<br />
UnicodeChar: WideChar; { the translated Unicode character }<br />
AsciiChar: Char; { the translated ASCII character }<br />
ShiftState: TEnhancedShiftState;<br />
Flags: Byte;<br />
end;<br />
<br />
TEnhancedShiftState is a set of TEnhancedShiftStateElement, which is defined as:<br />
TEnhancedShiftStateElement = (<br />
essShift, { either Left or Right Shift is pressed }<br />
essLeftShift,<br />
essRightShift,<br />
essCtrl, { either Left or Right Ctrl is pressed }<br />
essLeftCtrl,<br />
essRightCtrl,<br />
essAlt, { either Left or Right Alt is pressed, but *not* AltGr }<br />
essLeftAlt,<br />
essRightAlt, { only on keyboard layouts, without AltGr }<br />
essAltGr, { only on keyboard layouts, with AltGr instead of Right Alt }<br />
essCapsLockPressed,<br />
essCapsLockOn,<br />
essNumLockPressed,<br />
essNumLockOn,<br />
essScrollLockPressed,<br />
essScrollLockOn<br />
);<br />
<br />
A special value NilEnhancedKeyEvent is used to indicate no key event available in the result of PollEnhancedKeyEvent:<br />
{ The Nil value for the enhanced key event }<br />
NilEnhancedKeyEvent: TEnhancedKeyEvent = (<br />
VirtualKeyCode: 0;<br />
VirtualScanCode: 0;<br />
UnicodeChar: #0;<br />
AsciiChar: #0;<br />
ShiftState: [];<br />
Flags: 0;<br />
);<br />
<br />
* '''git:''' 0b8a0fb4<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Support for symbolicating Dwarf backtraces ===<br />
* '''Overview''': The -gl option now works with DWARF debug information on Darwin. This is the default for non-PowerPC Darwin targets, and the only support format for ARM and 64 bit Darwin targets.<br />
* '''Notes''': You have to also use the -Xg command line option when compiling the main program or library, to generate a .dSYM bundle that contains all debug information. You can also do this manually by calling ''dsymutil''<br />
* '''svn''': 49140<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Darwin/AArch64 (only macOS; iOS has not been tested), Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for the Z80 ===<br />
* '''Overview''': Support has been added for generating Z80 code.<br />
* '''More information''': [[Z80]]<br />
<br />
=== Support for the WebAssembly target ===<br />
* '''Overview''': Support has been added for generating WebAssembly code.<br />
* '''More information''': [[WebAssembly/Compiler]]<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_3.2.0&diff=145837User Changes 3.2.02021-07-17T14:19:01Z<p>PascalDragon: The change regarding accessing fields of a field that's a class is part of 3.2.0 already</p>
<hr />
<div>== About this page==<br />
<br />
Listed below are intentional changes made to the FPC compiler (3.2) since the [[User_Changes_3.0.4|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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_3.2|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Usage Changes ===<br />
<br />
==== Library search directories and custom sysroots ====<br />
* '''Old behaviour''': When specifying a custom sysroot (-XR), all library search directories (both built-in and specified via options) were relative to this sysroot<br />
* '''New behaviour''': Library search directories are only relative to the sysroot if they start with "=".<br />
* '''Reason''': Allow specifying custom search directories for libraries outside a sysroot.<br />
* '''Remedy''': Add "=" at the start of library search paths if you wish them to be relative to any specified sysroot.<br />
* '''Example''':<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl=/opt/X11/lib''': will search for libraries in '''/Data/Developer/MacOSX10.4u.sdk/opt/X11/lib'''<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl=/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
* '''svn''': 43279, 43302, 43306, 43312<br />
<br />
==== Additional <syntaxhighlight lang="pascal" inline>{$include}</syntaxhighlight> variables ====<br />
; Overview<br />
: The [[$include|<syntaxhighlight lang="pascal" inline>{$include}</syntaxhighlight>]] directive now recognizes the additional internal variables<br />
:* <syntaxhighlight lang="pascal" inline>{$include %currentRoutine%}</syntaxhighlight><br />
:* <syntaxhighlight lang="pascal" inline>{$include %dateYear%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %dateMonth%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %dateDay%}</syntaxhighlight><br />
:* <syntaxhighlight lang="pascal" inline>{$include %timeHour%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %timeMinute%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %timeSecond%}</syntaxhighlight><br />
; Remedy<br />
: You cannot name and use environment variable expansion with any of those names.<br />
; svn<br />
: 30873 (current routine), 38329 (date and time)<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Dynamic array parameters are passed like pointers ====<br />
* '''Old behaviour''': When using the default calling convention, dynamic array parameters were passed on the stack.<br />
* '''New behaviour''': When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).<br />
* '''Reason''': Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.<br />
* '''Remedy''': Adjust pure assembler routines that have dynamic array parameters.<br />
* '''svn''': 30870, 30878, 31622<br />
<br />
==== VMT Interface table uses private variable FPC_EMPTYINTF ====<br />
* '''Old behaviour''': The vIntfTable field has three possible values: <br />
**Nil if the class doesn't implement any interface (but an ancestor might)<br />
**A pointer to an interface table (with count <> 0) if the class implements any interface<br />
**A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface<br />
* '''New behaviour''': The vIntfTable field has two possible values:<br />
**Nil if neither the class nor any ancestor implements an interface<br />
**A pointer to an interface table in any other case<br />
* '''Reason''': FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems<br />
* '''Remedy''': Adjust code accordingly<br />
* '''svn''': 34087<br />
<br />
==== Modeswitch ''TypeHelpers'' in Delphi modes enables ''type helper''-syntax ====<br />
* '''Old behaviour''': The modeswitch ''TypeHelpers'' is enabled by default in Delphi modes and allows to extend primitive types with ''record helper'' types.<br />
* '''New behaviour''':<br />
**The modeswitch is no longer set by default.<br />
**Primitive types can always be extended by record helpers in Delphi modes.<br />
**The modeswitch enables the ''type helper''-syntax as known from non-Delphi modes.<br />
* '''Reason''': The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.<br />
* '''Remedy''': The only problems arise if one disabled the modeswitch on purpose which now no longer disallows the extension of primitive types.<br />
* '''svn''': 37225<br />
<br />
==== Class references in a class VMT's field table ====<br />
* '''Old behaviour''': The class array of the vFieldTable of the VMT contains an array of TClass entries<br />
* '''New behaviour''': The class array of the vFieldTable of the VMT contains an array of PClass entries<br />
* '''Reason''': As for the RTTI the indirect references are necessary for dynamic packages.<br />
* '''Remedy''': Use an additional dereferentiation to access the class type.<br />
* '''svn''': 37485<br />
<br />
==== Property field access lists no longer allows classes ====<br />
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.<br />
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.<br />
* '''Reason''':<br />
** Delphi compatibility<br />
** This resulted in an internal error for published properties<br />
* '''Remedy''':<br />
** Switch the fields to records or objects<br />
** Use a method with inline modifier that will result in similar performance<br />
* '''svn''': 40656<br />
* '''Example''': The following code now fails:<br />
<syntaxhighlight lang="pascal"><br />
unit Test;<br />
{$mode objfpc}<br />
<br />
interface<br />
<br />
type<br />
TTest1 = class<br />
Field: String;<br />
end;<br />
<br />
TTest2 = class<br />
private<br />
fTest1: TTest1;<br />
public<br />
property Prop: String read fTest1.Field; // Error "Record or object type expected"<br />
end;<br />
<br />
implementation<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
=== Language Changes ===<br />
<br />
==== Visibility of generic type parameters ====<br />
* '''Old behaviour''': Type parameters of generics had ''public'' visibility.<br />
* '''New behaviour''': Type parameters of generics now have ''strict private'' visibility.<br />
* '''Reason''': With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [http://bugs.freepascal.org/view.php?id=25917 this] bug report). Also the fix is Delphi compatible.<br />
* '''Remedy''': Declare a type alias for the type parameter with the desired visibility.<br />
* '''Example''': In the following example ''T'' is declared as ''strict private'', while ''TAlias'' is declared as ''public'' and thus can be used as before the change.<br />
<syntaxhighlight lang="pascal"><br />
type<br />
generic TTest<T> = class<br />
public type<br />
TAlias = T;<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Parsing of ''specialize'' has been changed ====<br />
* '''Old behaviour''': ''specialize'' was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.<br />
* '''New behaviour''': ''specialize'' is now considered part of the specialized type, just as ''generic'' is. This means that unit names and parent types need to be used before the part containing the ''specialize''.<br />
* '''Reason''': This allows for a more logical usage of ''specialize'' in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.<br />
* '''Remedy''': Put the ''specialize'' directly in front of the type which needs to be specialized.<br />
<br />
==== Operator overload ''+'' no longer allowed for dynamic arrays ====<br />
* '''Old behaviour''': The ''+'' operator could be overloaded for dynamic array types.<br />
* '''New behaviour''': The ''+'' operator for dynamic array types can no longer be overloaded if the modeswitch ''ArrayOperators'' is active (default in Delphi modes).<br />
* '''Reason''': When the modeswitch ''ArrayOperators'' is active a ''+'' operator is now provided by the compiler itself which concatenates two arrays together.<br />
* '''Remedy''':<br />
** Disable the modeswitch (for Delphi modes this can be done with ''{$modeswitch ArrayOperators-}'').<br />
** If your operator merely concatenates two arrays then remove the overload.<br />
** If your operator does something different or more then use a different operator.<br />
* '''Note''': A warning is provided by the compiler if an overload is in scope, but not used due to the internal operator.<br />
<br />
==== Generic type parameters need to match ====<br />
* '''Old behaviour''': When defining the method of a generic class or record it was possible to use different names for the type parameters than those that were used in the declaration.<br />
* '''New behaviour''': The order and name of generic type parameters of the class or record type in the method definition has to match the order and name of generic types parameters of the class or record declaration.<br />
* '''Reason''': To avoid the user making mistakes e.g. when the order of parameters is swapped. Also this is compatible to at least newer Delphi versions.<br />
* '''Remedy''': Use the correct generic type parameters for the definition.<br />
* '''svn''': 39701<br />
<br />
==== Visibility of methods implementing interface methods ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces<br />
* '''New behaviour''': Only methods visible in the class that is declared as implementing the method are considered.<br />
* '''Reason''': The symbol visibility rules should be respected in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Make (strict) private methods that should implement interface methods in descendant classes protected or public.<br />
* '''svn''': 40645<br />
<br />
==== Methods implementing interface methods and overloads ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces.<br />
* '''New behaviour''': In case of overloads, searching stops when a method is found that has the right name but not the ''overload'' directive. Note that this directive is automatically inherited when overriding a method.<br />
* '''Reason''': The same happens when calling a method, and the symbol resolution rules should be the same in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Add an ''overload'' directive to methods of which all overloads should be visible in the entire class hierarchy.<br />
* '''Example''':<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw27349.pp?r1=40683&r2=40682&pathrev=40683 Bug found by this change] (previously, on non-Windows platforms the '''_Addref''' method of ''TInterfacedObject'' was selected for implementing by the classes implementing ''tmyintf'').<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbf/tb0267.pp?view=markup Example that no longer compiles].<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbs/tb0654.pp?view=markup Fixed example].<br />
* '''svn''': 40683<br />
<br />
==== Objective-C "Related Result Type" ====<br />
* '''Old behaviour''': The type checking system always evaluated calls to Objective-C methods as them returning the declared result type.<br />
* '''New behaviour''': The type checking system now takes into account the [http://releases.llvm.org/8.0.0/tools/clang/docs/LanguageExtensions.html#objective-c-features "related result type"] rule from Objective-C. This means that certain methods are now assumed to always return an instance whose type is compatible with the object to which the message was sent (i.e., it's the same, or inherits from it). This is done for the following methods, provided their declared result type is also compatible with the class type in which the method is declared:<br />
** instance methods whose first lower case word in the message name is ''init'' or ''new''<br />
** class methods whose first lower case word in the message name is ''autorelease'', ''init'', ''retain'', or ''self''<br />
* '''Reason''': Compatibility with translations of more recent versions of Cocoa headers<br />
* '''Remedy''': Normally this should not break existing, correct code. If it does, you can probably fix it by removing superfluous typecasts.<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
{$modeswitch objectivec1}<br />
<br />
type<br />
FPCMyType = objcclass<br />
function init: id; message 'init';<br />
class function alloc: FPCMyType; message 'initWithValue';<br />
// since ObjCBool is not related to FPCMyType, the "related result type" rule will not apply here<br />
// even though the message starts with "retain" and it's a class method<br />
class function retainCounting: ObjCBool; message 'retainCounting';<br />
end;<br />
<br />
...<br />
<br />
var<br />
a: NSArray;<br />
begin<br />
// will give an error even though FPCMyType returns 'id', because 'id' is related to<br />
// FPCMyType and hence the compiler will now interpret the 'init' message as returning<br />
// an "FPCMyType" when called. Do note that the actual return type of "init" remains<br />
// "id" in all other contexts, e.g. when deciding override compatibility. The declaration<br />
// of that method is not modified, and the only changed behviour is that when calling it<br />
// the result type is statically assumed to be of FPCMyType.<br />
a:=FPCMyType.alloc.init;<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': r42816<br />
<br />
=== RTTI changes ===<br />
<br />
==== RTTI for Interfaces (published property count) ====<br />
* '''Old behavior''': The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count. <br />
* '''New behavior''': Before the property RTTI data is now a Word count field that specifies the amount of properties<br />
* '''Reason''': Both user request and usability.<br />
* '''Remedy''': Adjust pointer offsets accessing the property data accordingly.<br />
<br />
==== RTTI for COM Interfaces (IID String) ====<br />
* '''Old behavior''': COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.<br />
* '''New behavior''': The undocumented field has been removed.<br />
* '''Reason''': The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.<br />
* '''Remedy''': Use the GUID field and convert that to a String.<br />
<br />
==== RTTI Binary format change ====<br />
* '''Old behavior''': References to other types are designated by PTypeInfo.<br />
* '''New behavior''': References to other types are designated by PPTypeInfo.<br />
* '''Reason''': While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.<br />
* '''Remedy''': If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.<br />
* '''Note''': <br />
**The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.<br />
**This does not apply to TObject.ClassInfo which still returns a PTypeInfo<br />
<br />
==== RTTI for Corba Interfaces (IID String) ====<br />
* '''Old behavior''': IIDStr is a field of TTypeData.<br />
* '''New behavior''': IIDStr is a property of TTypeData.<br />
* '''Reason''': The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.<br />
* '''Remedy''': If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.<br />
* '''svn''': 35026<br />
<br />
==== Reference to Record Init Information ====<br />
* '''Old behavior''': Field RecSize follows directly after start of TTypeData record.<br />
* '''New behavior''': Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).<br />
* '''Reason''': With the record init information one can more quickly decide whehther a record needs to be classed as ''managed'' or not which is among others useful for the IsManaged() function of the Rtti unit.<br />
* '''Remedy''': If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.<br />
* '''Note''': The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.<br />
* '''svn''': 35125, 35134<br />
<br />
==== TOrdType extended ====<br />
* '''Old behavior''': TOrdType contains entries for 8-, 16- and 32-bit widths.<br />
* '''New behavior''': TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.<br />
* '''Reason''': Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.<br />
* '''Remedy''': Adjust arrays that have TOrdType as index.<br />
* '''svn''': 35135<br />
<br />
==== New OrdType field for tkInt64 and tkQWord ====<br />
* '''Old behavior''': MinInt64Value and MinQWordValue follow directly after start of TTypeData record.<br />
* '''New behavior''': MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.<br />
* '''Reason''': To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.<br />
* '''Remedy''': If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.<br />
* '''svn''': 35135<br />
<br />
==== First field of TProcedureParam changed ====<br />
* '''Old behavior''': First field of TProcedureParam is called Flags and has type Byte.<br />
* '''New behavior''': First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.<br />
* '''Reason''': Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.<br />
* '''Remedy''': Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.<br />
* '''svn''': 35174<br />
<br />
==== TParamFlag extended for constref ====<br />
* '''Old behavior''': TParamFlag has no entry for constref parameters.<br />
* '''New behavior''': TParamFlag has entry pfConstRef for constref parameters.<br />
* '''Reason''': To correctly detect constref parameters they need to be marked accordingly.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).<br />
* '''svn''': 35175<br />
<br />
==== Ranges of Boolean types adjusted ====<br />
* '''Old behavior''': ByteBool, WordBool and LongBool have a range of 0..-1.<br />
* '''New behavior''': ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).<br />
* '''Reason''': The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.<br />
* '''Remedy''': Adjust code that might have relied on the range being ''invalid''.<br />
* '''svn''': 35184<br />
<br />
==== OrdType of Boolean64 and QWordBool adjusted ====<br />
* '''Old behavior''': Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.<br />
* '''New behavior''': Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.<br />
* '''Reason''': Both types have a size of 64-bit thus using a smaller size is incorrect.<br />
* '''Remedy''': Use the correct fields to retrieve the range boundaries of the types.<br />
* '''svn''': 35185<br />
<br />
==== All Boolean types have TypeKind tkBool ====<br />
* '''Old behavior''': Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.<br />
* '''New behavior''': Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.<br />
* '''Reason''': Consistency and possibility to differentiate ordinary subranges from the real Boolean types.<br />
* '''Remedy''': Check for TypeKind tkBool instead of some "magic" to detect Boolean types.<br />
* '''Note''': Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.<br />
* '''svn''': 35186, 35187<br />
<br />
==== TParamFlag extended for hidden parameters ====<br />
* '''Old behavior''': TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1<br />
* '''New behavior''': TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2<br />
* '''Reason''': As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).<br />
* '''svn''': 35267, 35286, 35291<br />
<br />
==== Parameters of method pointer variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of method pointer variables only listed visible parameters.<br />
* '''New behavior''': The parameters of method pointer variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
==== Parameters of procedure variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of procedure variables only listed visible parameters.<br />
* '''New behavior''': The parameters of procedure variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
==== Implicit default values for real, pointer and string properties ====<br />
* '''Old behavior''': Real, pointer and string properties had no implicit values. Zero values and empty strings were stored by default.<br />
* '''New behavior''': Real, pointer and string properties have got implicit default values of 0 or `` respectively. As a result these values are not stored by default anymore.<br />
* '''Reason''': 1. Delphi compatibilty. 2. The ''default'' modifier cannot be used for these properties - there was no possibility to set 0 or `` default values in FPC 3.0.x.<br />
* '''Remedy''': The ''nodefault'' modifier must be added to the property declaration.<br />
* '''More details''': Check the [https://www.freepascal.org/docs-html/ref/refsu38.html documentation] for more information. There were more fixes regarding string storage handling as well.<br />
* '''svn''': 37954<br />
<br />
=== Unit changes ===<br />
<br />
==== SysUtils ====<br />
<br />
===== faSymlink =====<br />
* '''Old behaviour:''' faSymlink had the numerical value $40. This was wrong on windows, and not compatible with Delphi.<br />
* '''New behaviour:''' faSymlink has the numerical value $400. Correct on windows.<br />
* '''Reason for change:''' Wrong functionality and Delphi compatibility.<br />
* '''Remedy:''' If you are using the old numerical constant $40, simply use faSymlink instead.<br />
* '''svn:''' r33340<br />
<br />
===== FileExists on Unix-based systems =====<br />
* '''Old behaviour:''' ''FileExists'' returns ''True'' for existing directories.<br />
* '''New behaviour:''' ''FileExists'' does not return ''True'' for existing directories.<br />
* '''Reason for change:''' Directories are not files, thus it was illogical for ''FileExists'' to return ''True'' for existing directories. Also this brings it in line with Windows and Delphi.<br />
* '''Remedy:''' Use ''DirectoryExists'' to check for the existance of a directory<br />
* '''svn:''' r43111<br />
<br />
==== Classes.TList auto-growth ====<br />
* '''Old behaviour:''' Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity<br />
* '''New behaviour:''' Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.<br />
* '''Reason for change:''' Avoid out-of-memory when very large lists are expanded<br />
* '''svn:''' 34462<br />
<br />
==== Math Min/Max ====<br />
* '''Old behaviour:''' Mixing of QWord and Int64 was possible as there was no QWord overload. However the result might have been wrong.<br />
* '''New behaviour:''' Overload for QWord exists now but mixed calls with Int64/QWord cause a compiler error.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Apply an explicit typecast to one of the parameters so both are of the same type.<br />
* '''svn:''' 39995<br />
<br />
==== StrUtils AnsiStartsText/AnsiEndsText ====<br />
* '''Old behaviour:''' AnsiStartsText or AnsiEndsText would return false for empty substring. This is not in line with Delphi, which returns true.<br />
* '''New behaviour:''' AnsiStartsText or AnsiEndsText now return True for empty substring.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Check explicitly for empty string if you counted on the old behaviour.<br />
* '''svn:''' 38768<br />
<br />
==== Types IStream interface and Classes TStreamAdapter ====<br />
* '''Old behaviour:''' IStream Interface (classes unit and jwa units) used Int64 for various out parameters.<br />
* '''New behaviour:''' IStream Interface (classes unit and jwa units) use QWord for various out parameters.<br />
* '''Reason for change:''' The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.<br />
* '''Remedy:''' If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.<br />
* '''svn:''' 32820 and 35542<br />
<br />
==== Baseunix (Linux only) ====<br />
* '''Old behaviour:''' stat was an union, with one side the proper posix fieldnames, and the other deprecated, simplified 1.0.x fieldnames. The 1.0.x were already marked as deprecated for 2 major cycles.<br />
* '''New behaviour:''' Deprecated 1.0.x fieldnames removed.<br />
* '''Reason for change:''' Left over 1.0.x transition feature. Incompatible with other *nix ports. <br />
* '''Remedy:''' Update fieldnames <br />
* '''svn:''' 39644 and 39655<br />
<br />
==== Classes TStrings.LoadFromStream/File encoding handling ====<br />
* '''Old behaviour:''' The LoadFromStream call totally ignored the encoding of a file, loading it from a stream without regard for encoding, unless an encoding was specified. <br />
* '''New behaviour:''' There is an overloaded call with a Boolean parameter 'IgnoreEncoding' which determines whether the encoding should be taken into account or not. By default, this parameter is False, meaning that LoadFromStream with just a stream as argument now calls the encoding-aware version of LoadFromStream, passing it an encoding of Nil, which mean the default encoding will be used.<br />
* '''Reason for change:''' Delphi compatibility, and the corresponding changes in TStringStream constructors.<br />
* '''Remedy:''' The old behaviour can be restored by setting the IgnoreEncoding parameter to 'True'.<br />
* '''svn:''' 37962 and 37965<br />
<br />
===== TStringStream now observes system encoding =====<br />
* '''Old behaviour''': TStringStream copied bytes as-is from the string specified in the constructor. <br />
* '''New behaviour''': Now bytes are fetched from the string using the encoding of the string.<br />
* '''Reason:''' Delphi-compatibility<br />
* '''Remedy:''' Pass a string with the correct encoding to TStringStream<br />
* '''svn''': 36758<br />
<br />
===== TStringStream derives from TBytesStream =====<br />
* '''Old behaviour''': ''TStringStream'' is derived from TStream.<br />
* '''New behaviour''': ''TStringStream'' is derived from ''TBytesStream'' which in turn derives from ''TMemoryStream''.<br />
* '''Reason:'''<br />
** needed for the above mentioned observing of the system encoding<br />
** Delphi-compatibility<br />
* '''Remedy:''' You need to adjust checks for inheritance.<br />
* '''svn''': 36758<br />
<br />
==== DB ====<br />
===== TParam.LoadFromFile sets share mode to fmShareDenyWrite =====<br />
* '''Old behaviour''': TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file<br />
* '''New behaviour''': TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file<br />
* '''Remedy''': If your application requires exclusive access to file specify fmShareExclusive<br />
<br />
===== CodePage aware TStringField and TMemoField =====<br />
* '''Old behaviour''': These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.<br />
* '''New behaviour''': When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.<br />
<br />
===== ODBC headers on Unix platforms defaults to 3.52 version =====<br />
* '''Old behaviour''': default was ODBCVER $0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.<br />
* '''New behaviour''': default is ODBCVER $0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).<br />
<br />
===== TBlobData opaque type reworked to TBytes =====<br />
* '''Old behaviour''': TBlobData was declared as Ansistring<br />
* '''New behaviour''': TBlobData is declared as TBytes <br />
* '''Reason for change''': Delphi compatibility. Also helps to avoid possible code page recodings.<br />
* '''Remedy''': If your application used TBlobData as a string, you can use AsString for parameters, or convert to TBytes.<br />
<br />
==== FGL ====<br />
===== Declaration of type TTypeList changed =====<br />
* '''Old behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''array[0..GMaxListSize] of T''.<br />
* '''New behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''PT''.<br />
* '''Reason''': The way ''GMaxListSize'' was declared this could lead to too large static array types so that compilation aborted with a ''Data segment too large'' error. This also might have lead to incorrect range errors if range checking was turned on. As FPC supports indexed access to pointer types potential type problems when using the ''List'' property should be minimal.<br />
* '''Remedy''': If your application relies on ''PTypeList'' to be a static array type (instead of merely being indexable like an array) then you'll need to adjust your code.<br />
* '''svn''': 39464<br />
<br />
==== objcbase ====<br />
* '''Old behaviour''': The Objective-C BOOL type was represented by objcbase.BOOL, which was the same as a Pascal boolean on all platforms.<br />
* '''New behaviour''': The Objective-C BOOL type is now represented by objcbase.ObjCBOOL, which maps to a boolean type that always corresponds to the one used in Objective-C (it differs on some platforms)<br />
* '''Reason''': The renaming was to prevent name clashes, and the type definition change was to fix interfacing issues between Objective-Pascal and Objective-C<br />
* '''Remedy''': change all uses of Boolean and BOOL in Objective-Pascal method definitions to ObjCBool.<br />
* '''svn''': 42483<br />
<br />
==== SimpleIPC ====<br />
* '''Old behaviour''': ReadMessage is a procedure.<br />
* '''New behaviour''': ReadMessage is a function, returning a boolean, telling you whether a message was actually read.<br />
* '''Reason''': Provide more information to the user. <br />
* '''Remedy''': Handle the result if necessary. (if you used OnMessage, no change is necessary)<br />
* '''svn''': 36916<br />
<br />
<br />
==== Process Unit ====<br />
<br />
===== RunCommand =====<br />
* '''Old behaviour:''' RunCommand had a few short sleeps to reduce CPU usage when the called process ran long.<br />
* '''New behaviour:''' RunCommand defaults to no sleep unless poRunIdle is passed to the default parameter with process options.<br />
* '''Reason for change:''' Applications that ran binaries to quickly obtain information were stalled by the pauses for no good reason. Servicing both short and long running binaries adequately without additional info seemed impossible due to slightly differing OS behaviours in pipe reading.<br />
* '''Remedy:''' For short living processes that start up quickly: do nothing. For long running processes, pass poRunIdle as process option.<br />
* '''svn:''' this changes was merged post RC1<br />
<br />
===== poNoConsole on Windows =====<br />
* '''Old behaviour:''' On Windows, poNoConsole mapped to Win API DETACH_PROCESS which still created standard input/output/error handles.<br />
* '''New behaviour:''' poNoConsole maps to CREATE_NO_WINDOW, which doesn't create input/output/error handles. A new option poDetached allows for DETACH_PROCESS.<br />
* '''Reason for change:''' poNoConsole still created a window in cases. (mantis [https://bugs.freepascal.org/view.php?id=32055 bug 32055]). <br />
* '''Remedy:''' If you try to hide the console but still need stdin/stdout handles, then poNoConsole no longer works. You could try poDetached. See also [https://forum.lazarus.freepascal.org/index.php/topic,49631.msg360286.html#msg360286 podetached forum thread]<br />
* '''svn:''' the poDetached option was created post RC1<br />
<br />
==== fpHTTPClient and fpHTTPServer Units ====<br />
* '''Old behaviour:''' Old units had SSL support hardcoded built in using OpenSSL.<br />
* '''New behaviour:''' A program returns the error "No SSL Socket support compiled in" when doing a HTTPS request.<br />
* '''Reason for change:''' pluggable architecture for SSL support.<br />
* '''Remedy:''' Add one of the units ''opensslsockets'' (OpenSSL) or ''gnutlssockets'' (GNU TLS) to the uses clause of your program.<br />
<br />
== Linux/Android platforms ==<br />
<br />
=== GNU Binutils 2.19.1 or later are required by default ===<br />
* '''Old behaviour''': The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"<br />
* '''New behaviour''': The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.<br />
* '''Reason''': Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).<br />
* '''Remedy''': If you have a system with an older version of GNU Binutils, you can use the new ''-X9'' command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.<br />
<br />
=== Stack alignment on Linux/i386 ===<br />
* '''Old behaviour''': The stack alignment for Linux/i386 was 4 bytes.<br />
* '''New behaviour''': The stack alignment for Linux/i386 is 16 bytes.<br />
* '''Reason''': Compatibility with the current Linux/i386 ABI and code generated by other Linux/i386 compilers.<br />
* '''Remedy''': This change will generally only impact inline assembly code that calls subroutines. If you have such code, ensure the stack is aligned to a multiple of 16 bytes before calling any subroutine. You may also have to realign the stack to 16 bytes after routines return in case they use a calling convention whereby the callee removes any stack arguments.<br />
<br />
== i386 platforms ==<br />
<br />
=== -Ooasmcse/{$optimization asmcse} has been removed ===<br />
* '''Old behaviour''': The compiler contained an assembler common subexpression elimination pass for the i386 platform.<br />
* '''New behaviour''': This optimisation pass has been removed from the compiler.<br />
* '''Reason''': That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.<br />
* '''Remedy''': Don't use -Ooasmcse/{$optimization asmcse} anymore.<br />
<br />
== i8086 platforms ==<br />
<br />
=== the codepointer type has been changed in the small and compact memory models ===<br />
<br />
* '''Old behaviour''': The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''New behaviour''': The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''Reason''': Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.<br />
* '''Remedy''': If your program uses the small memory model and needs any kind of fixing, you're very likely to get compile time type checking errors, since the Pointer and CodePointer types are no longer compatible. To fix these, change all your pointers that point to code to CodePointer instead of Pointer. Alternatively, if your program is really small (code+data<=64k), you can switch to the tiny memory model, where the Pointer and CodePointer types are still compatible. If your program uses the compact memory model, it is unlikely to get any sort of breakage, since the Pointer and CodePointer types were already incompatible in this memory model.<br />
* '''svn''': 38691<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Default Target macOS version ===<br />
* '''Old behaviour''': The default target version for the i386 (Intel 32 bits) platform was Mac OS X 10.4 (Tiger), and for the x86-64 (Intel 64 bits) was Mac OS X 10.5 (Leopard).<br />
* '''New behaviour''': The default target version for both the i386 (Intel 32 bits) and x86-64 (Intel 64 bits) platforms is now OS X 10.8 (Mountain Lion).<br />
* '''Reason''': On macOS 10.14, installing the command line tools no longer places the crt*.o files required when targeting the older targets in the same location as before, resulting in the need for custom command line options and modifications to fpc.cfg.<br />
* '''Remedy''': If you wish to target those earlier operating system versions, use the ''-WM10.4'' resp. ''-WM10.5'' command line parameters of the compiler, and if necessary point it to an SDK that still contains support for those operating system versions with the ''-XR/path/to/SDK'' parameter (and, if necessary, to an assembler/linker that supports removed architectures with ''-FD/path/to/clang_and_ld'').<br />
* '''svn''': 43374<br />
<br />
=== Darwin/i386 and calling conventions whereby the callee removes stack parameters ===<br />
* '''Old behaviour''': The Darwin/i386 code generator treated all calling conventions as "caller removes stack parameters", even for calling conventions where this is normally not the case.<br />
* '''New behaviour''': The Darwin/i386 code generator correctly handles calling conventions whereby the callee removes the stack parameters. In particular, this changes the behaviour for the ''register'', ''stdcall'', ''safecall'', and ''pascal'' calling conventions.<br />
* '''Reason''': Respect calling conventions, compatibility with other platforms and compilers.<br />
* '''Remedy''': If you have inline assembly code that dealt with this special behaviour of Darwin/i386 under older FPC versions, you can disable it for FPC 3.2 and later. Darwin/i386 now behaves according to the same (new) rules as [[User_Changes_3.2#Stack_alignment_on_Linux.2Fi386|Linux/i386]].<br />
* '''svn''': r43650<br />
<br />
== Windows platforms ==<br />
<br />
=== GNU Binutils 2.25 or later are required by default ===<br />
* '''Old behaviour''': If the binary of a unit contains too many sections ( > $7fff) it fails to compile, due to the binary format not supporting that many sections.<br />
* '''New behaviour''': If the binary of a unit contains many sections ( > $7fff) it will be compiled using the BigObj format of COFF.<br />
* '''Reason''': Some units (e.g. ''packages\odata\src\sharepoint.pp'') got so large that they could no longer be compiled using the normal COFF format. The internal assembler and linker can handle this format as can the GNU binutils, but only starting from 2.25 on.<br />
* '''Remedy''': If you compile with the binutils instead of using the internal assembler/linker then either use an up to date version of the binutils (>= 2.25) or if you really need to use an older version, then pass -a5 which will disable the use of BigObj COFF files, though you'll then not be able to build the whole FPC distribution nor will you be able to link to such big units.<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=145836User Changes Trunk2021-07-17T14:18:33Z<p>PascalDragon: The change regarding accessing fields of a field that's a class is part of 3.2.0 already</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Range checking for enumeration constants in Delphi mode ====<br />
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.<br />
* '''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.<br />
* '''Reason''': Delphi-compatibility.<br />
* '''Remedy''': Fix the range errors.<br />
* '''svn''': 42272, 42275<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068 <br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217, 47219, 47220, 47221<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
==== Sha1 ====<br />
* '''Old behaviour:''' Sha1file silently did nothing on file not found.<br />
* '''New behaviour:''' sha1file now raises sysconst.sfilenotfound exception on fle not found.<br />
* '''Reason for change:''' Behaviour was not logical, other units in the same package already used sysutils.<br />
* '''svn''': 49166<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_talk:PascalDragon&diff=144418User talk:PascalDragon2021-04-12T09:33:03Z<p>PascalDragon: /* Dead links */</p>
<hr />
<div>=Dead links=<br />
all 3 bottom-of-page links (See also this announcement e-mail) are dead. [[User:Alextpp|Alextpp]] ([[User talk:Alextpp|talk]]) 20:17, 28 March 2021 (CEST)<br />
<br />
Do you have an explicit lists of non-working links, cause right now I don't know which you mean... --[[User:PascalDragon|PascalDragon]] ([[User talk:PascalDragon|talk]]) 10:04, 30 March 2021 (CEST)<br />
<br />
I do, [[User:Alextpp|Alextpp]] ([[User talk:Alextpp|talk]]) 19:10, 31 March 2021 (CEST)<br />
<br />
* http://lists.freepascal.org/lists/fpc-announce/2012-December/000586.html<br />
* http://lists.freepascal.org/lists/fpc-devel/2012-December/030714.html<br />
* http://lists.freepascal.org/lists/fpc-announce/2013-February/000587.html<br />
<br />
I also meant where they're referenced. Right now I don't even know where the first one is used... --[[User:PascalDragon|PascalDragon]] ([[User talk:PascalDragon|talk]]) 11:33, 12 April 2021 (CEST)<br />
<br />
= Blatant advertising =<br />
Hi Sven, saw that you were interested in native support for C++ linking (cppclass). Just wanted to let you know (if you did not already) that there is a FPC port of SWIG that generates object-oriented FPC code from C++ files<br />
Perhaps that could be useful?<br />
See fpc mailing list post:<br />
http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg30349.html<br />
where d.l.i.w. linked an updated version...<br />
...and I put the resulting code in<br />
https://bitbucket.org/reiniero/smalltools/src<br />
(directory SWIGDelphi)<br />
<br />
Thanks,<br />
Reinier<br />
<br />
--[[User:BigChimp|BigChimp]] 06:10, 22 February 2013 (UTC)<br />
<br />
I'm aware of SWIG and I'll maybe use it in the coming months in the context of my master thesis, but I'm talking about compiler support for linking to C++ code. Since some years already FPC knows the "cppclass" keyword for defining a C++ class and two of my first patches for FPC where small corrections and improvements it (see [http://bugs.freepascal.org/view.php?id=15082 here] and [http://bugs.freepascal.org/view.php?id=16248 here] and so one can currently already use class methods of C++ classes (of course this is not nearly enough).<br />
<br />
Regards,<br />
Sven<br />
<br />
Thanks, Sven. Good luck with the thesis!<br />
--[[User:BigChimp|BigChimp]] 09:27, 23 February 2013 (UTC)<br />
<br />
[[User:PascalDragon|PascalDragon]] 13:39, 22 February 2013 (UTC)</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_talk:PascalDragon&diff=144223User talk:PascalDragon2021-03-30T08:04:38Z<p>PascalDragon: /* Dead links */</p>
<hr />
<div>=Dead links=<br />
all 3 bottom-of-page links (See also this announcement e-mail) are dead. [[User:Alextpp|Alextpp]] ([[User talk:Alextpp|talk]]) 20:17, 28 March 2021 (CEST)<br />
<br />
Do you have an explicit lists of non-working links, cause right now I don't know which you mean... --[[User:PascalDragon|PascalDragon]] ([[User talk:PascalDragon|talk]]) 10:04, 30 March 2021 (CEST)<br />
<br />
= Blatant advertising =<br />
Hi Sven, saw that you were interested in native support for C++ linking (cppclass). Just wanted to let you know (if you did not already) that there is a FPC port of SWIG that generates object-oriented FPC code from C++ files<br />
Perhaps that could be useful?<br />
See fpc mailing list post:<br />
http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg30349.html<br />
where d.l.i.w. linked an updated version...<br />
...and I put the resulting code in<br />
https://bitbucket.org/reiniero/smalltools/src<br />
(directory SWIGDelphi)<br />
<br />
Thanks,<br />
Reinier<br />
<br />
--[[User:BigChimp|BigChimp]] 06:10, 22 February 2013 (UTC)<br />
<br />
I'm aware of SWIG and I'll maybe use it in the coming months in the context of my master thesis, but I'm talking about compiler support for linking to C++ code. Since some years already FPC knows the "cppclass" keyword for defining a C++ class and two of my first patches for FPC where small corrections and improvements it (see [http://bugs.freepascal.org/view.php?id=15082 here] and [http://bugs.freepascal.org/view.php?id=16248 here] and so one can currently already use class methods of C++ classes (of course this is not nearly enough).<br />
<br />
Regards,<br />
Sven<br />
<br />
Thanks, Sven. Good luck with the thesis!<br />
--[[User:BigChimp|BigChimp]] 09:27, 23 February 2013 (UTC)<br />
<br />
[[User:PascalDragon|PascalDragon]] 13:39, 22 February 2013 (UTC)</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=144200User Changes Trunk2021-03-27T19:59:01Z<p>PascalDragon: Document BasicEventCreate change</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Property field access lists no longer allows classes ====<br />
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.<br />
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.<br />
* '''Reason''':<br />
** Delphi compatibility<br />
** This resulted in an internal error for published properties<br />
* '''Remedy''':<br />
** Switch the fields to records or objects<br />
** Use a method with inline modifier that will result in similar performance<br />
* '''svn''': 40656<br />
* '''Example''': The following code now fails:<br />
<syntaxhighlight lang="pascal"><br />
unit Test;<br />
{$mode objfpc}<br />
<br />
interface<br />
<br />
type<br />
TTest1 = class<br />
Field: String;<br />
end;<br />
<br />
TTest2 = class<br />
private<br />
fTest1: TTest1;<br />
public<br />
property Prop: String read fTest1.Field; // Error "Record or object type expected"<br />
end;<br />
<br />
implementation<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' <br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Range checking for enumeration constants in Delphi mode ====<br />
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.<br />
* '''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.<br />
* '''Reason''': Delphi-compatibility.<br />
* '''Remedy''': Fix the range errors.<br />
* '''svn''': 42272, 42275<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== System - buffering of output to text files ====<br />
<br />
* '''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).<br />
* '''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).<br />
* '''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).<br />
* '''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.<br />
* '''svn:''' 46863<br />
<br />
==== System - type returned by BasicEventCreate on Windows ====<br />
<br />
* '''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.<br />
* '''New behaviour:''' BasicEventCreate returns solely the Windows Event handle.<br />
* '''Reason for change:''' This way the returned handle can be directly used in the Windows ''Wait*''-functions which is especially apparent in ''TEventObject.Handle''.<br />
* '''Remedy:''' If you need the last error code after a failed wait, use ''GetLastOSError'' instead.<br />
* '''svn:''' 49068 <br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
===== DB.TFieldType: new types added =====<br />
* '''Old behaviour:''' .<br />
* '''New behaviour:''' Some of new Delphi field types were added (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) + corresponding classes TLongWordField, TShortIntField, TByteField<br />
* '''Reason for change:''' align with Delphi and open space for support of short integer and unsigned integer data types<br />
* '''svn''': 47217<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
== AArch64/ARM64 ==<br />
=== ''{''-style comments no longer supported in assembler blocks ===<br />
* '''Old behaviour''': The ''{'' character started a comment in assembler blocks, like in Pascal<br />
* '''New behaviour''': The ''{'' character now has a different meaning in the AArch64 assembler reader, so it can no longer be used to start comments.<br />
* '''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 ''{''.<br />
* '''Remedy''': Use ''(*'' or ''//'' to start comments<br />
* '''svn''': 47116<br />
<br />
<br />
== Darwin/iOS ==<br />
=== The Darwin targets corresponding to iOS have been renamed to iOS ===<br />
* '''Old behaviour:''' The Darwin/ARM and Darwin/AArch64 (ARM64) targets generated code for iOS running on those architectures.<br />
* '''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)<br />
* '''Reason for change:''' The switch of the macOS platform to AArch64 <br />
* '''svn''': 45762<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_2.6.0&diff=142249FPC New Features 2.6.02021-01-10T10:21:27Z<p>PascalDragon: Document the Bsf*/Bsr* overloads</p>
<hr />
<div>{{FPC_New_Features}}<br />
<br />
== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_2.4.4|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Better support for Delphi-compatible classes ====<br />
* '''Overview''': Support has been added for nested types (including other classes), class variables and class-local constants.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': [[class_extensions_examples]] lists several examples that make use of these features.<br />
<br />
==== Advanced record syntax ====<br />
* '''Overview''': Support has been added for advanced record syntax (as Delphi calls it) including record visibility sections, nested types and constants, record methods, static fields, properties, class constructors, class destructors and class operators.<br />
* '''Notes''': Delphi-compatible. Record (instance) constructors are not implemented yet.<br />
* '''More information''':<br />
** http://docwiki.embarcadero.com/RADStudio/en/Structured_Types#Records_.28advanced.29<br />
** http://docwiki.embarcadero.com/RADStudio/en/Operator_Overloading_(Delphi)<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/terecs_u1.pp<br />
<br />
==== Enumerators in records ====<br />
* '''Overview''': Previous FPC versions allowed ''enumerator'' structures to be classes, objects or interfaces. Now ''enumerator'' structure can also be defined as a record (using advanced record syntax only).<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tforin25.pp<br />
<br />
==== Support for class and record helpers ====<br />
* '''Overview''': Support has been added for class and record helpers which allow you to add methods, properties and enumerators to classes and records without inheriting from them.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** [[Helper types]] contains a detailed description of the feature<br />
** The tests are named ''thlp*.pp'', ''tchlp*.pp'' and ''trhlp*.pp'' and available in http://svn.freepascal.org/svn/fpc/trunk/tests/test/<br />
<br />
==== Generic records, arrays and procedural types ====<br />
* '''Overview''': Previous FPC versions only supported generic classes, objects and interfaces. Now it is also possible to define generic records, generic arrays and generic procedural types.<br />
* '''Notes''': Generics are available both in ObjFPC and Delphi modes and generic records/arrays/procedural variables are defined similar to generic classes. Support for Delphi's generic syntax has been added but still may be not 100% compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric24.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric25.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric26.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric27.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric28.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric32.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric33.pp<br />
<br />
==== Scoped enumerations ====<br />
* '''Overview''': Support for the ''{$scopedenums on/off}'' directive has been added. The elements of enumerations defined as a ''scoped enumeration'' can only be used by fully qualifying them via ''typename.element''.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsscopedenums_xml.html<br />
<br />
==== Custom deprecated messages ====<br />
* '''Overview''': ''Deprecated'' can now be applied to virtually any syntactic element (including constants and units), and it is also possible to specify a custom deprecation message.<br />
* '''Notes''': Delphi-compatible<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
unit OldUnit deprecated 'Use NewUnit instead';<br />
<br />
interface<br />
<br />
implementation<br />
<br />
procedure OldRoutine; deprecated 'Use NewRoutine instead';<br />
begin<br />
end;<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for the Objective-Pascal dialect ====<br />
* '''Overview''': On macOS, most system frameworks are written in Objective-C. While it is possible to interface them via a procedural API, this is not very convenient. For this reason, the Macintosh Pascal community has created a new dialect called Objective-Pascal that enables seamless interacting with Objective-C code.<br />
* '''Notes''': This new dialect is currently only supported on Darwin-based platforms (including iOS) using the Apple Objective-C runtime. Patches to add support for the GNUStep runtime are welcome.<br />
* '''More information''':<br />
** [[FPC_PasCocoa]] explains the basic language definitions.<br />
** [[FPC_PasCocoa/Differences]] explains some of the differences between Objective-Pascal and on the one hand Object Pascal, and on the other hand Objective-C.<br />
<br />
====Constref parameter modifier====<br />
* '''Overview''': A new parameter modifier called ''constref'' has been added, similar to the existing ''var'', ''const'' and ''out'' ones. This modifier means that the compiler can assume that the parameter is constant, and that it must be passed by reference. Its most obvious usage is to translate ''const *'' parameters from C headers.<br />
* '''Notes''': The main reason it was introduced was to enable writing a cross-platform interface for XPCOM, as explained on the [[User_Changes_2.6.0#IInterface.QueryInterface.2C_._AddRef_and_._Release_definitions_have_been_changed|User Changes 2.6.0]] page. Note that in general, it should only be used for interfacing with external code or when writing assembler routines. In other cases, letting the compiler decide how to pass the parameter is more likely to result in optimal code on most platforms in the long term.<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
procedure test(constref l: longint);<br />
begin<br />
writeln('This parameter has been passed by reference, although the Pascal code does not really care about that: ',l);<br />
end;<br />
<br />
begin<br />
test(5);<br />
end.<br />
</syntaxhighlight><br />
<br />
====Basic ISO Standard Pascal support====<br />
* '''Overview''': A language mode supporting ISO 7185 Standard Pascal has been added. It can be activated via the ''-Miso'' command line switch, or via the ''{$mode iso}'' compiler directive.<br />
* '''Notes''': This support is not yet complete. In particular, no ISO Standard Pascal compatible I/O is available yet (get, put, ...)<br />
* '''More information''': http://www.moorecad.com/standardpascal/standards.html<br />
<br />
====Support for nested procedure variables====<br />
* '''Overview''': It is now possible to define procedure variables that are assignment-compatible with nested procedures and functions. This feature is enabled by default in ''{$mode macpas}'' and ''{$mode iso}'', and can be enabled in other syntax modes by adding ''{$modeswitch nestedprocvars}'' to your source file. Note that it is possible to also assign regular (non-nested) procedures/functions to a nested procedure variable, and to call them that way.<br />
* '''Notes''': Enabling this feature changes the calling convention used for nested procedures/functions. This will break code from the Turbo Pascal era that uses nested procedures/functions as callbacks from collection iterators in the ''objects'' unit.<br />
* '''More information''': A procedure variable type can hold a reference to nested routines in two cases:<br />
** when it is declared [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3a.pp inline in the parameter list of another function/procedure] (ISO-style declaration). This form of declaring procedure variable types is only available when ''nestedprocvars'' are enabled.<br />
** when it is declared as [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3d.pp is nested], similar to ''of object'' for "procedure of object" types. Note that in this second case, it is possible to write invalid code: if you assign a nested routine to nested procedure variable and then exit the nested routine's parent stack frame, calling the nested procedure variable will result in undefined bahaviour.<br />
<br />
====Support for non-local goto's====<br />
* '''Overview''': It is now possible to ''goto'' to a ''label'' defined in another procedure, e.g. to quickly exit from a deeply nested procedure to a less deeply nested one.<br />
* '''Notes''': Enabled by default in ''ISO'' and ''MacPas'' syntax modes, can be enabled in other modes via ''{$modeswitch nonlocalgoto}''. It is not possible to use a non-local goto to jump over stack frames that require finalisation (e.g., when they contain reference counted types).<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmacnonlocalgoto.pp<br />
<br />
====Support for &-escaping of keywords====<br />
* '''Overview''': The & sign can now be used to escape language keywords, so they can be used as identifiers.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/webtbs/tw15930.pp<br />
<br />
====Support for ''univ'' parameters in MacPas mode====<br />
* '''Overview''': Previous FPC versions simply ignored the ''univ'' qualifier for parameters. Now, FPC will properly parse it and interpret it like other Mac Pascal compilers: it allows passing any parameter whose size matches the size of the declared parameter.<br />
* '''Notes''': Only enabled in ''{$mode macpas}''. Abusing this feature can easily result in crashes or corrupted data in case the declared parameter type and the actual parameter have to be passed to the subroutine in different ways according to the calling convention. In general, this feature should only be used to port legacy code.<br />
* '''More information''': http://bugs.freepascal.org/view.php?id=15777<br />
<br />
====CExtended floating point type====<br />
* '''Overview''': This type is the same as the regular ''extended'' type in terms of precision, but it conforms to the properties/behaviour of the equivalent of the ''Extended'' type in C. In practice, this means that ''CExtended'' corresponds to ''long double'' on i386 and x86_64 platforms that support an 80 bits ''extended'' type, and to ''double'' on other platforms. This is mainly required for fields in records that are translated from C in order to guarantee proper field alignments, and also for parameters to C routines.<br />
* '''Notes''': At this time, FPC does not support an equivalent of C's ''long double'' type on platforms other than the ones mentioned above. Since ''Extended'' is an alias for ''Double'' on these other platforms in FPC, ''CExtended'' is also an alias for ''double'' there.<br />
* '''More information''': /<br />
<br />
====SAR intrinsics====<br />
* '''Overview''': Support has been added for ''shift arithmetic right'' (SAR) intrinsics.<br />
* '''Notes''': Unlike the ''SHL'' and ''SHR'' operators, ''SAR'' is not implemented as an operator but as an intrinsic. It is also defined using different names for different integer sizes to prevent unexpected results when applying it to expressions. The functions are named as follows:<br />
** ''SarShortInt'' (8-bit)<br />
** ''SarSmallInt'' (16-bit)<br />
** ''SarLongInt'' (32-bit)<br />
** ''SarInt64'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/tsar1.pp<br />
<br />
====ROL/ROR intrinsics====<br />
* '''Overview''': Support has been added for ''ROL'' (Rotate Overflow Left) and ''ROR'' (Rotate Overflow Right) intrinsics. These shift a value left or right, inserting bits that were shifted out at the other side of the value.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities. They look like this:<br />
** ''RolByte'' / ''RorByte'' (8-bit)<br />
** ''RolWord'' / ''RorByte'' (16-bit)<br />
** ''RolDWord'' / ''RorDWord'' (32-bit)<br />
** ''RolQWord'' / ''RorQWord'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/trox1.pp<br />
<br />
====Bitscan intrinsics====<br />
* '''Overview''': Support has been added for ''BSF'' (Bit Scan Forward) and ''BSR'' (Bit Scan Reverse) intrinsics.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities. They look like this:<br />
** ''BsfByte'' / ''BsrByte'' (8-bit)<br />
** ''BsfWord'' / ''BsrWord'' (16-bit)<br />
** ''BsfDWord'' / ''BsrDWord'' (32-bit)<br />
** ''BsfQWord'' / ''BsrQWord'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tbsx1.pp<br />
<br />
==== Boolean16, Boolean32 and Boolean64 types ====<br />
* '''Overview''': Support has been added for ''Boolean16'', ''Boolean32'' and ''Boolean64'' types<br />
* '''Notes''': These new Boolean types behave like the standard pascal type ''Boolean'' except that their size is 2, 4 or 8 bytes. This is useful to interface with some libraries.<br />
* '''More information''': The existing ''WordBool'', ''LongBool'' and ''QWordBool'' types assume false=0 and true<>0. With the new types false=0 and true=1, while any other value is invalid.<br />
<br />
==ARM systems==<br />
<br />
===Support for VFPv2 and VFPv3===<br />
* '''Overview''': Support has been added for the ARM Vector Floating Point (VFP) units versions 2 and 3. This is the floating point unit that's usually included on, a.o., Cortex-A8 and Cortex-A9 family CPUs, and in the iOS-based devices.<br />
* '''Notes''': When targeting a CPU that implements the ARMv6 or later architecture, you ''must'' also use ''-Cparmv6'' at the same time. The reason is that saving/restoring the VFP unit's context must occur using different instructions prior to ARMv6. ''-Cparmv6'' is enabled by default for iOS targets though, because all such devices are at least ARMv6. Additionally, FPC only supports the so-called ''softfp'' ABI for VFP: the VFP unit is used to perform the calculations, but the used calling convention to pass floating point values is the same as for soft-float.<br />
* '''More information''': Activate using the ''-Cfvfpv2'' resp. ''-Cfvfpv3'' command line parameters.<br />
<br />
===Support for Thumb-2===<br />
* '''Overview''': Support has been added to generate Thumb-2 code for the ARMv7-M architecture as implemented in the Cortex-M3 family.<br />
* '''Notes''': This architecture is currently only supported for no-OS targets (embedded); it does not yet work for iOS or Linux.<br />
* '''More information''': Activate using the ''-Cparmv7m'' or ''-Cpcortexm3'' command line parameters.<br />
<br />
==IA32/i386 systems==<br />
<br />
===Support for the iPhoneSim target===<br />
* '''Overview''': As of Xcode 3.2.4, the iPhoneSimulator target uses a different Objective-C ABI than regular i386 code. Therefore a new target called ''iphonesim'' was added to the compiler.<br />
* '''Notes''': If you are still using an earlier version of Xcode to develop iPhoneSimulator-based code, use the regular Darwin/i386 target.<br />
* '''More information''': use the ''-Tiphonesim'' command line parameter to select this target. When compiling the FPC packages for this target, this will also compile a special version of ''MacOSAll'' that only contains APIs available for this target.<br />
<br />
== New Features from other versions ==<br />
<br />
{{Navbar Lazarus Release Notes}}</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_2.6.0&diff=142248FPC New Features 2.6.02021-01-10T10:20:15Z<p>PascalDragon: Document the Rol*/Ror* overloads</p>
<hr />
<div>{{FPC_New_Features}}<br />
<br />
== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_2.4.4|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Better support for Delphi-compatible classes ====<br />
* '''Overview''': Support has been added for nested types (including other classes), class variables and class-local constants.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': [[class_extensions_examples]] lists several examples that make use of these features.<br />
<br />
==== Advanced record syntax ====<br />
* '''Overview''': Support has been added for advanced record syntax (as Delphi calls it) including record visibility sections, nested types and constants, record methods, static fields, properties, class constructors, class destructors and class operators.<br />
* '''Notes''': Delphi-compatible. Record (instance) constructors are not implemented yet.<br />
* '''More information''':<br />
** http://docwiki.embarcadero.com/RADStudio/en/Structured_Types#Records_.28advanced.29<br />
** http://docwiki.embarcadero.com/RADStudio/en/Operator_Overloading_(Delphi)<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/terecs_u1.pp<br />
<br />
==== Enumerators in records ====<br />
* '''Overview''': Previous FPC versions allowed ''enumerator'' structures to be classes, objects or interfaces. Now ''enumerator'' structure can also be defined as a record (using advanced record syntax only).<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tforin25.pp<br />
<br />
==== Support for class and record helpers ====<br />
* '''Overview''': Support has been added for class and record helpers which allow you to add methods, properties and enumerators to classes and records without inheriting from them.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** [[Helper types]] contains a detailed description of the feature<br />
** The tests are named ''thlp*.pp'', ''tchlp*.pp'' and ''trhlp*.pp'' and available in http://svn.freepascal.org/svn/fpc/trunk/tests/test/<br />
<br />
==== Generic records, arrays and procedural types ====<br />
* '''Overview''': Previous FPC versions only supported generic classes, objects and interfaces. Now it is also possible to define generic records, generic arrays and generic procedural types.<br />
* '''Notes''': Generics are available both in ObjFPC and Delphi modes and generic records/arrays/procedural variables are defined similar to generic classes. Support for Delphi's generic syntax has been added but still may be not 100% compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric24.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric25.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric26.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric27.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric28.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric32.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric33.pp<br />
<br />
==== Scoped enumerations ====<br />
* '''Overview''': Support for the ''{$scopedenums on/off}'' directive has been added. The elements of enumerations defined as a ''scoped enumeration'' can only be used by fully qualifying them via ''typename.element''.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsscopedenums_xml.html<br />
<br />
==== Custom deprecated messages ====<br />
* '''Overview''': ''Deprecated'' can now be applied to virtually any syntactic element (including constants and units), and it is also possible to specify a custom deprecation message.<br />
* '''Notes''': Delphi-compatible<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
unit OldUnit deprecated 'Use NewUnit instead';<br />
<br />
interface<br />
<br />
implementation<br />
<br />
procedure OldRoutine; deprecated 'Use NewRoutine instead';<br />
begin<br />
end;<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for the Objective-Pascal dialect ====<br />
* '''Overview''': On macOS, most system frameworks are written in Objective-C. While it is possible to interface them via a procedural API, this is not very convenient. For this reason, the Macintosh Pascal community has created a new dialect called Objective-Pascal that enables seamless interacting with Objective-C code.<br />
* '''Notes''': This new dialect is currently only supported on Darwin-based platforms (including iOS) using the Apple Objective-C runtime. Patches to add support for the GNUStep runtime are welcome.<br />
* '''More information''':<br />
** [[FPC_PasCocoa]] explains the basic language definitions.<br />
** [[FPC_PasCocoa/Differences]] explains some of the differences between Objective-Pascal and on the one hand Object Pascal, and on the other hand Objective-C.<br />
<br />
====Constref parameter modifier====<br />
* '''Overview''': A new parameter modifier called ''constref'' has been added, similar to the existing ''var'', ''const'' and ''out'' ones. This modifier means that the compiler can assume that the parameter is constant, and that it must be passed by reference. Its most obvious usage is to translate ''const *'' parameters from C headers.<br />
* '''Notes''': The main reason it was introduced was to enable writing a cross-platform interface for XPCOM, as explained on the [[User_Changes_2.6.0#IInterface.QueryInterface.2C_._AddRef_and_._Release_definitions_have_been_changed|User Changes 2.6.0]] page. Note that in general, it should only be used for interfacing with external code or when writing assembler routines. In other cases, letting the compiler decide how to pass the parameter is more likely to result in optimal code on most platforms in the long term.<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
procedure test(constref l: longint);<br />
begin<br />
writeln('This parameter has been passed by reference, although the Pascal code does not really care about that: ',l);<br />
end;<br />
<br />
begin<br />
test(5);<br />
end.<br />
</syntaxhighlight><br />
<br />
====Basic ISO Standard Pascal support====<br />
* '''Overview''': A language mode supporting ISO 7185 Standard Pascal has been added. It can be activated via the ''-Miso'' command line switch, or via the ''{$mode iso}'' compiler directive.<br />
* '''Notes''': This support is not yet complete. In particular, no ISO Standard Pascal compatible I/O is available yet (get, put, ...)<br />
* '''More information''': http://www.moorecad.com/standardpascal/standards.html<br />
<br />
====Support for nested procedure variables====<br />
* '''Overview''': It is now possible to define procedure variables that are assignment-compatible with nested procedures and functions. This feature is enabled by default in ''{$mode macpas}'' and ''{$mode iso}'', and can be enabled in other syntax modes by adding ''{$modeswitch nestedprocvars}'' to your source file. Note that it is possible to also assign regular (non-nested) procedures/functions to a nested procedure variable, and to call them that way.<br />
* '''Notes''': Enabling this feature changes the calling convention used for nested procedures/functions. This will break code from the Turbo Pascal era that uses nested procedures/functions as callbacks from collection iterators in the ''objects'' unit.<br />
* '''More information''': A procedure variable type can hold a reference to nested routines in two cases:<br />
** when it is declared [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3a.pp inline in the parameter list of another function/procedure] (ISO-style declaration). This form of declaring procedure variable types is only available when ''nestedprocvars'' are enabled.<br />
** when it is declared as [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3d.pp is nested], similar to ''of object'' for "procedure of object" types. Note that in this second case, it is possible to write invalid code: if you assign a nested routine to nested procedure variable and then exit the nested routine's parent stack frame, calling the nested procedure variable will result in undefined bahaviour.<br />
<br />
====Support for non-local goto's====<br />
* '''Overview''': It is now possible to ''goto'' to a ''label'' defined in another procedure, e.g. to quickly exit from a deeply nested procedure to a less deeply nested one.<br />
* '''Notes''': Enabled by default in ''ISO'' and ''MacPas'' syntax modes, can be enabled in other modes via ''{$modeswitch nonlocalgoto}''. It is not possible to use a non-local goto to jump over stack frames that require finalisation (e.g., when they contain reference counted types).<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmacnonlocalgoto.pp<br />
<br />
====Support for &-escaping of keywords====<br />
* '''Overview''': The & sign can now be used to escape language keywords, so they can be used as identifiers.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/webtbs/tw15930.pp<br />
<br />
====Support for ''univ'' parameters in MacPas mode====<br />
* '''Overview''': Previous FPC versions simply ignored the ''univ'' qualifier for parameters. Now, FPC will properly parse it and interpret it like other Mac Pascal compilers: it allows passing any parameter whose size matches the size of the declared parameter.<br />
* '''Notes''': Only enabled in ''{$mode macpas}''. Abusing this feature can easily result in crashes or corrupted data in case the declared parameter type and the actual parameter have to be passed to the subroutine in different ways according to the calling convention. In general, this feature should only be used to port legacy code.<br />
* '''More information''': http://bugs.freepascal.org/view.php?id=15777<br />
<br />
====CExtended floating point type====<br />
* '''Overview''': This type is the same as the regular ''extended'' type in terms of precision, but it conforms to the properties/behaviour of the equivalent of the ''Extended'' type in C. In practice, this means that ''CExtended'' corresponds to ''long double'' on i386 and x86_64 platforms that support an 80 bits ''extended'' type, and to ''double'' on other platforms. This is mainly required for fields in records that are translated from C in order to guarantee proper field alignments, and also for parameters to C routines.<br />
* '''Notes''': At this time, FPC does not support an equivalent of C's ''long double'' type on platforms other than the ones mentioned above. Since ''Extended'' is an alias for ''Double'' on these other platforms in FPC, ''CExtended'' is also an alias for ''double'' there.<br />
* '''More information''': /<br />
<br />
====SAR intrinsics====<br />
* '''Overview''': Support has been added for ''shift arithmetic right'' (SAR) intrinsics.<br />
* '''Notes''': Unlike the ''SHL'' and ''SHR'' operators, ''SAR'' is not implemented as an operator but as an intrinsic. It is also defined using different names for different integer sizes to prevent unexpected results when applying it to expressions. The functions are named as follows:<br />
** ''SarShortInt'' (8-bit)<br />
** ''SarSmallInt'' (16-bit)<br />
** ''SarLongInt'' (32-bit)<br />
** ''SarInt64'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/tsar1.pp<br />
<br />
====ROL/ROR intrinsics====<br />
* '''Overview''': Support has been added for ''ROL'' (Rotate Overflow Left) and ''ROR'' (Rotate Overflow Right) intrinsics. These shift a value left or right, inserting bits that were shifted out at the other side of the value.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities. They look like this:<br />
** ''RolByte'' / ''RorByte'' (8-bit)<br />
** ''RolWord'' / ''RorByte'' (16-bit)<br />
** ''RolDWord'' / ''RorDWord'' (32-bit)<br />
** ''RolQWord'' / ''RorQWord'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/trox1.pp<br />
<br />
====Bitscan intrinsics====<br />
* '''Overview''': Support has been added for ''BSF'' (Bit Scan Forward) and ''BSR'' (Bit Scan Reverse) intrinsics.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tbsx1.pp<br />
<br />
==== Boolean16, Boolean32 and Boolean64 types ====<br />
* '''Overview''': Support has been added for ''Boolean16'', ''Boolean32'' and ''Boolean64'' types<br />
* '''Notes''': These new Boolean types behave like the standard pascal type ''Boolean'' except that their size is 2, 4 or 8 bytes. This is useful to interface with some libraries.<br />
* '''More information''': The existing ''WordBool'', ''LongBool'' and ''QWordBool'' types assume false=0 and true<>0. With the new types false=0 and true=1, while any other value is invalid.<br />
<br />
==ARM systems==<br />
<br />
===Support for VFPv2 and VFPv3===<br />
* '''Overview''': Support has been added for the ARM Vector Floating Point (VFP) units versions 2 and 3. This is the floating point unit that's usually included on, a.o., Cortex-A8 and Cortex-A9 family CPUs, and in the iOS-based devices.<br />
* '''Notes''': When targeting a CPU that implements the ARMv6 or later architecture, you ''must'' also use ''-Cparmv6'' at the same time. The reason is that saving/restoring the VFP unit's context must occur using different instructions prior to ARMv6. ''-Cparmv6'' is enabled by default for iOS targets though, because all such devices are at least ARMv6. Additionally, FPC only supports the so-called ''softfp'' ABI for VFP: the VFP unit is used to perform the calculations, but the used calling convention to pass floating point values is the same as for soft-float.<br />
* '''More information''': Activate using the ''-Cfvfpv2'' resp. ''-Cfvfpv3'' command line parameters.<br />
<br />
===Support for Thumb-2===<br />
* '''Overview''': Support has been added to generate Thumb-2 code for the ARMv7-M architecture as implemented in the Cortex-M3 family.<br />
* '''Notes''': This architecture is currently only supported for no-OS targets (embedded); it does not yet work for iOS or Linux.<br />
* '''More information''': Activate using the ''-Cparmv7m'' or ''-Cpcortexm3'' command line parameters.<br />
<br />
==IA32/i386 systems==<br />
<br />
===Support for the iPhoneSim target===<br />
* '''Overview''': As of Xcode 3.2.4, the iPhoneSimulator target uses a different Objective-C ABI than regular i386 code. Therefore a new target called ''iphonesim'' was added to the compiler.<br />
* '''Notes''': If you are still using an earlier version of Xcode to develop iPhoneSimulator-based code, use the regular Darwin/i386 target.<br />
* '''More information''': use the ''-Tiphonesim'' command line parameter to select this target. When compiling the FPC packages for this target, this will also compile a special version of ''MacOSAll'' that only contains APIs available for this target.<br />
<br />
== New Features from other versions ==<br />
<br />
{{Navbar Lazarus Release Notes}}</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_2.6.0&diff=142247FPC New Features 2.6.02021-01-10T10:18:44Z<p>PascalDragon: Documented the Sar* overloads</p>
<hr />
<div>{{FPC_New_Features}}<br />
<br />
== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_2.4.4|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Better support for Delphi-compatible classes ====<br />
* '''Overview''': Support has been added for nested types (including other classes), class variables and class-local constants.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': [[class_extensions_examples]] lists several examples that make use of these features.<br />
<br />
==== Advanced record syntax ====<br />
* '''Overview''': Support has been added for advanced record syntax (as Delphi calls it) including record visibility sections, nested types and constants, record methods, static fields, properties, class constructors, class destructors and class operators.<br />
* '''Notes''': Delphi-compatible. Record (instance) constructors are not implemented yet.<br />
* '''More information''':<br />
** http://docwiki.embarcadero.com/RADStudio/en/Structured_Types#Records_.28advanced.29<br />
** http://docwiki.embarcadero.com/RADStudio/en/Operator_Overloading_(Delphi)<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/terecs_u1.pp<br />
<br />
==== Enumerators in records ====<br />
* '''Overview''': Previous FPC versions allowed ''enumerator'' structures to be classes, objects or interfaces. Now ''enumerator'' structure can also be defined as a record (using advanced record syntax only).<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tforin25.pp<br />
<br />
==== Support for class and record helpers ====<br />
* '''Overview''': Support has been added for class and record helpers which allow you to add methods, properties and enumerators to classes and records without inheriting from them.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''':<br />
** [[Helper types]] contains a detailed description of the feature<br />
** The tests are named ''thlp*.pp'', ''tchlp*.pp'' and ''trhlp*.pp'' and available in http://svn.freepascal.org/svn/fpc/trunk/tests/test/<br />
<br />
==== Generic records, arrays and procedural types ====<br />
* '''Overview''': Previous FPC versions only supported generic classes, objects and interfaces. Now it is also possible to define generic records, generic arrays and generic procedural types.<br />
* '''Notes''': Generics are available both in ObjFPC and Delphi modes and generic records/arrays/procedural variables are defined similar to generic classes. Support for Delphi's generic syntax has been added but still may be not 100% compatible.<br />
* '''More information''':<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric24.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric25.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric26.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric27.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric28.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric32.pp<br />
** http://svn.freepascal.org/svn/fpc/trunk/tests/test/tgeneric33.pp<br />
<br />
==== Scoped enumerations ====<br />
* '''Overview''': Support for the ''{$scopedenums on/off}'' directive has been added. The elements of enumerations defined as a ''scoped enumeration'' can only be used by fully qualifying them via ''typename.element''.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsscopedenums_xml.html<br />
<br />
==== Custom deprecated messages ====<br />
* '''Overview''': ''Deprecated'' can now be applied to virtually any syntactic element (including constants and units), and it is also possible to specify a custom deprecation message.<br />
* '''Notes''': Delphi-compatible<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
unit OldUnit deprecated 'Use NewUnit instead';<br />
<br />
interface<br />
<br />
implementation<br />
<br />
procedure OldRoutine; deprecated 'Use NewRoutine instead';<br />
begin<br />
end;<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Support for the Objective-Pascal dialect ====<br />
* '''Overview''': On macOS, most system frameworks are written in Objective-C. While it is possible to interface them via a procedural API, this is not very convenient. For this reason, the Macintosh Pascal community has created a new dialect called Objective-Pascal that enables seamless interacting with Objective-C code.<br />
* '''Notes''': This new dialect is currently only supported on Darwin-based platforms (including iOS) using the Apple Objective-C runtime. Patches to add support for the GNUStep runtime are welcome.<br />
* '''More information''':<br />
** [[FPC_PasCocoa]] explains the basic language definitions.<br />
** [[FPC_PasCocoa/Differences]] explains some of the differences between Objective-Pascal and on the one hand Object Pascal, and on the other hand Objective-C.<br />
<br />
====Constref parameter modifier====<br />
* '''Overview''': A new parameter modifier called ''constref'' has been added, similar to the existing ''var'', ''const'' and ''out'' ones. This modifier means that the compiler can assume that the parameter is constant, and that it must be passed by reference. Its most obvious usage is to translate ''const *'' parameters from C headers.<br />
* '''Notes''': The main reason it was introduced was to enable writing a cross-platform interface for XPCOM, as explained on the [[User_Changes_2.6.0#IInterface.QueryInterface.2C_._AddRef_and_._Release_definitions_have_been_changed|User Changes 2.6.0]] page. Note that in general, it should only be used for interfacing with external code or when writing assembler routines. In other cases, letting the compiler decide how to pass the parameter is more likely to result in optimal code on most platforms in the long term.<br />
* '''More information''':<br />
<br />
<syntaxhighlight lang=pascal><br />
procedure test(constref l: longint);<br />
begin<br />
writeln('This parameter has been passed by reference, although the Pascal code does not really care about that: ',l);<br />
end;<br />
<br />
begin<br />
test(5);<br />
end.<br />
</syntaxhighlight><br />
<br />
====Basic ISO Standard Pascal support====<br />
* '''Overview''': A language mode supporting ISO 7185 Standard Pascal has been added. It can be activated via the ''-Miso'' command line switch, or via the ''{$mode iso}'' compiler directive.<br />
* '''Notes''': This support is not yet complete. In particular, no ISO Standard Pascal compatible I/O is available yet (get, put, ...)<br />
* '''More information''': http://www.moorecad.com/standardpascal/standards.html<br />
<br />
====Support for nested procedure variables====<br />
* '''Overview''': It is now possible to define procedure variables that are assignment-compatible with nested procedures and functions. This feature is enabled by default in ''{$mode macpas}'' and ''{$mode iso}'', and can be enabled in other syntax modes by adding ''{$modeswitch nestedprocvars}'' to your source file. Note that it is possible to also assign regular (non-nested) procedures/functions to a nested procedure variable, and to call them that way.<br />
* '''Notes''': Enabling this feature changes the calling convention used for nested procedures/functions. This will break code from the Turbo Pascal era that uses nested procedures/functions as callbacks from collection iterators in the ''objects'' unit.<br />
* '''More information''': A procedure variable type can hold a reference to nested routines in two cases:<br />
** when it is declared [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3a.pp inline in the parameter list of another function/procedure] (ISO-style declaration). This form of declaring procedure variable types is only available when ''nestedprocvars'' are enabled.<br />
** when it is declared as [http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmaclocalprocparam3d.pp is nested], similar to ''of object'' for "procedure of object" types. Note that in this second case, it is possible to write invalid code: if you assign a nested routine to nested procedure variable and then exit the nested routine's parent stack frame, calling the nested procedure variable will result in undefined bahaviour.<br />
<br />
====Support for non-local goto's====<br />
* '''Overview''': It is now possible to ''goto'' to a ''label'' defined in another procedure, e.g. to quickly exit from a deeply nested procedure to a less deeply nested one.<br />
* '''Notes''': Enabled by default in ''ISO'' and ''MacPas'' syntax modes, can be enabled in other modes via ''{$modeswitch nonlocalgoto}''. It is not possible to use a non-local goto to jump over stack frames that require finalisation (e.g., when they contain reference counted types).<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tmacnonlocalgoto.pp<br />
<br />
====Support for &-escaping of keywords====<br />
* '''Overview''': The & sign can now be used to escape language keywords, so they can be used as identifiers.<br />
* '''Notes''': Delphi-compatible.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/webtbs/tw15930.pp<br />
<br />
====Support for ''univ'' parameters in MacPas mode====<br />
* '''Overview''': Previous FPC versions simply ignored the ''univ'' qualifier for parameters. Now, FPC will properly parse it and interpret it like other Mac Pascal compilers: it allows passing any parameter whose size matches the size of the declared parameter.<br />
* '''Notes''': Only enabled in ''{$mode macpas}''. Abusing this feature can easily result in crashes or corrupted data in case the declared parameter type and the actual parameter have to be passed to the subroutine in different ways according to the calling convention. In general, this feature should only be used to port legacy code.<br />
* '''More information''': http://bugs.freepascal.org/view.php?id=15777<br />
<br />
====CExtended floating point type====<br />
* '''Overview''': This type is the same as the regular ''extended'' type in terms of precision, but it conforms to the properties/behaviour of the equivalent of the ''Extended'' type in C. In practice, this means that ''CExtended'' corresponds to ''long double'' on i386 and x86_64 platforms that support an 80 bits ''extended'' type, and to ''double'' on other platforms. This is mainly required for fields in records that are translated from C in order to guarantee proper field alignments, and also for parameters to C routines.<br />
* '''Notes''': At this time, FPC does not support an equivalent of C's ''long double'' type on platforms other than the ones mentioned above. Since ''Extended'' is an alias for ''Double'' on these other platforms in FPC, ''CExtended'' is also an alias for ''double'' there.<br />
* '''More information''': /<br />
<br />
====SAR intrinsics====<br />
* '''Overview''': Support has been added for ''shift arithmetic right'' (SAR) intrinsics.<br />
* '''Notes''': Unlike the ''SHL'' and ''SHR'' operators, ''SAR'' is not implemented as an operator but as an intrinsic. It is also defined using different names for different integer sizes to prevent unexpected results when applying it to expressions. The functions are named as follows:<br />
** ''SarShortInt'' (8-bit)<br />
** ''SarSmallInt'' (16-bit)<br />
** ''SarLongInt'' (32-bit)<br />
** ''SarInt64'' (64-bit)<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/tsar1.pp<br />
<br />
====ROL/ROR intrinsics====<br />
* '''Overview''': Support has been added for ''ROL'' (Rotate Overflow Left) and ''ROR'' (Rotate Overflow Right) intrinsics. These shift a value left or right, inserting bits that were shifted out at the other side of the value.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/trox1.pp<br />
<br />
====Bitscan intrinsics====<br />
* '''Overview''': Support has been added for ''BSF'' (Bit Scan Forward) and ''BSR'' (Bit Scan Reverse) intrinsics.<br />
* '''Notes''': Just like for the [[FPC_New_Features_2.6.0#SAR_intrinsics|''SAR'' intrinsic]], separate versions have been added for different integer sizes in order to prevent any ambiguities.<br />
* '''More information''': http://svn.freepascal.org/svn/fpc/trunk/tests/test/tbsx1.pp<br />
<br />
==== Boolean16, Boolean32 and Boolean64 types ====<br />
* '''Overview''': Support has been added for ''Boolean16'', ''Boolean32'' and ''Boolean64'' types<br />
* '''Notes''': These new Boolean types behave like the standard pascal type ''Boolean'' except that their size is 2, 4 or 8 bytes. This is useful to interface with some libraries.<br />
* '''More information''': The existing ''WordBool'', ''LongBool'' and ''QWordBool'' types assume false=0 and true<>0. With the new types false=0 and true=1, while any other value is invalid.<br />
<br />
==ARM systems==<br />
<br />
===Support for VFPv2 and VFPv3===<br />
* '''Overview''': Support has been added for the ARM Vector Floating Point (VFP) units versions 2 and 3. This is the floating point unit that's usually included on, a.o., Cortex-A8 and Cortex-A9 family CPUs, and in the iOS-based devices.<br />
* '''Notes''': When targeting a CPU that implements the ARMv6 or later architecture, you ''must'' also use ''-Cparmv6'' at the same time. The reason is that saving/restoring the VFP unit's context must occur using different instructions prior to ARMv6. ''-Cparmv6'' is enabled by default for iOS targets though, because all such devices are at least ARMv6. Additionally, FPC only supports the so-called ''softfp'' ABI for VFP: the VFP unit is used to perform the calculations, but the used calling convention to pass floating point values is the same as for soft-float.<br />
* '''More information''': Activate using the ''-Cfvfpv2'' resp. ''-Cfvfpv3'' command line parameters.<br />
<br />
===Support for Thumb-2===<br />
* '''Overview''': Support has been added to generate Thumb-2 code for the ARMv7-M architecture as implemented in the Cortex-M3 family.<br />
* '''Notes''': This architecture is currently only supported for no-OS targets (embedded); it does not yet work for iOS or Linux.<br />
* '''More information''': Activate using the ''-Cparmv7m'' or ''-Cpcortexm3'' command line parameters.<br />
<br />
==IA32/i386 systems==<br />
<br />
===Support for the iPhoneSim target===<br />
* '''Overview''': As of Xcode 3.2.4, the iPhoneSimulator target uses a different Objective-C ABI than regular i386 code. Therefore a new target called ''iphonesim'' was added to the compiler.<br />
* '''Notes''': If you are still using an earlier version of Xcode to develop iPhoneSimulator-based code, use the regular Darwin/i386 target.<br />
* '''More information''': use the ''-Tiphonesim'' command line parameter to select this target. When compiling the FPC packages for this target, this will also compile a special version of ''MacOSAll'' that only contains APIs available for this target.<br />
<br />
== New Features from other versions ==<br />
<br />
{{Navbar Lazarus Release Notes}}</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=CDDB&diff=141357CDDB2020-12-02T08:39:10Z<p>PascalDragon: Added a warning regarding FreeDB no longer existing</p>
<hr />
<div>{{CDDB}}<br />
<br />
{{Warning|The source mentioned here is no longer available. However FPC itself provides a unit for CDDB as [https://www.freepascal.org/daily/packages/cdrom/fpcddb/index.html fpcddb]. An article that explains its use is available [https://www.freepascal.org/~michael/articles/cddb/cddb.pdf here]. }}<br />
<br />
{{Warning|The CDDB service on FreeDB is no longer available. An alternative is provided by GNUDB as [http://gnudb.gnudb.org/ http://gnudb.gnudb.org].}}<br />
<br />
<br />
=== About ===<br />
''CDDB'' is a simple unit for accessing CD track information from CDDB/FreeDB. There is little documentation but sample code is provided below.<br />
<br />
=== License ===<br />
[http://www.opensource.org/licenses/bsd-license.php BSD]<br />
<br />
=== Download ===<br />
The latest can be found [http://www.simmonsclan.net/fpc/cddb.pas here] - This link appears to be dead. Is there an active copy of this somewhere?<br />
<br />
=== Dependencies / System Requirements ===<br />
* Linux<br />
* Synapse httpsend unit<br />
<br />
=== Installation ===<br />
Copy the unit into the source directory for your project.<br />
<br />
=== Use ===<br />
The first step to accessing CDDB is creating TCDDB. This is where the connection and application information is defined. TCDDB has some default values so you don't have to define them all. The default server is [http://freedb.freedb.org FreeDB].<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure CreateCDDB;<br />
var<br />
CDDB: TCDDB;<br />
begin<br />
CDDB := TCDDB.Create;<br />
CDDB.ServerURL := 'http://freedb.freedb.org/~cddb/cddb.cgi'; // this is the server to access<br />
CDDB.ClientName := 'fpccddb'; // your application name that is passed to the server<br />
end;</syntaxhighlight><br />
<br />
First try using the MOTD (Message of the Day) command.<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnMOTDClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
cmd: TCDDBMOTD;<br />
begin<br />
CDDB := TCDDB.Create;<br />
cmd := TCDDBMOTD.Create(CDDB);<br />
try<br />
cmd.Execute;<br />
Memo1.Lines.Assign(cmd.MOTDResponse.Response);<br />
finally<br />
cmd.Free;<br />
CDDB.Free;<br />
end;<br />
end;</syntaxhighlight><br />
<br />
You can get a list of supported categories using TCDDBListCategories<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnCategoriesClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
cmd: TCDDBListCategories;<br />
begin<br />
CDDB := TCDDB.Create;<br />
cmd := TCDDBListCategories.Create(CDDB);<br />
try<br />
cmd.Execute;<br />
lbxCategories.Items.Assign(cmd.ListCategoriesResponse.Categories);<br />
finally<br />
cmd.Free;<br />
CDDB.Free;<br />
end;<br />
end;</syntaxhighlight><br />
<br />
This last example will query the database using the cdrom '/dev/cdrom'. The result is loaded into a TStringGrid named grdQueryResponse.<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnQueryClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
Cmd: TCDDBQuery;<br />
i: Integer;<br />
begin<br />
CDDB := TCDDB.Create;<br />
Cmd := TCDDBQuery.Create(CDDB);<br />
try<br />
Cmd.Device := '/dev/cdrom'<br />
try<br />
Cmd.Execute;<br />
except on E:Exception do<br />
begin<br />
ShowMessage(E.Message);<br />
Exit;<br />
end;<br />
end;<br />
<br />
with Cmd.QueryResponse do<br />
begin<br />
for i := 0 to ResponseCount-1 do<br />
begin<br />
grdQueryResponse.RowCount := grdQueryResponse.RowCount+1;<br />
grdQueryResponse.Cells[0,i+1] := Artist[i];<br />
grdQueryResponse.Cells[1,i+1] := Album[i];<br />
grdQueryResponse.Cells[2,i+1] := Category[i];<br />
grdQueryResponse.Cells[3,i+1] := DiscID[i];<br />
end;<br />
end;<br />
finally<br />
cmd.Free;<br />
CDDB.Free<br />
end;<br />
end;</syntaxhighlight><br />
<br />
[[Category:Components]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=CDDB&diff=141356CDDB2020-12-02T08:36:38Z<p>PascalDragon: Added reference to fpCDDB</p>
<hr />
<div>{{CDDB}}<br />
<br />
{{Warning|The source mentioned here is no longer available. However FPC itself provides a unit for CDDB as [https://www.freepascal.org/daily/packages/cdrom/fpcddb/index.html fpcddb]. An article that explains its use is available [https://www.freepascal.org/~michael/articles/cddb/cddb.pdf here]. }}<br />
<br />
<br />
=== About ===<br />
''CDDB'' is a simple unit for accessing CD track information from CDDB/FreeDB. There is little documentation but sample code is provided below.<br />
<br />
=== License ===<br />
[http://www.opensource.org/licenses/bsd-license.php BSD]<br />
<br />
=== Download ===<br />
The latest can be found [http://www.simmonsclan.net/fpc/cddb.pas here] - This link appears to be dead. Is there an active copy of this somewhere?<br />
<br />
=== Dependencies / System Requirements ===<br />
* Linux<br />
* Synapse httpsend unit<br />
<br />
=== Installation ===<br />
Copy the unit into the source directory for your project.<br />
<br />
=== Use ===<br />
The first step to accessing CDDB is creating TCDDB. This is where the connection and application information is defined. TCDDB has some default values so you don't have to define them all. The default server is [http://freedb.freedb.org FreeDB].<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure CreateCDDB;<br />
var<br />
CDDB: TCDDB;<br />
begin<br />
CDDB := TCDDB.Create;<br />
CDDB.ServerURL := 'http://freedb.freedb.org/~cddb/cddb.cgi'; // this is the server to access<br />
CDDB.ClientName := 'fpccddb'; // your application name that is passed to the server<br />
end;</syntaxhighlight><br />
<br />
First try using the MOTD (Message of the Day) command.<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnMOTDClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
cmd: TCDDBMOTD;<br />
begin<br />
CDDB := TCDDB.Create;<br />
cmd := TCDDBMOTD.Create(CDDB);<br />
try<br />
cmd.Execute;<br />
Memo1.Lines.Assign(cmd.MOTDResponse.Response);<br />
finally<br />
cmd.Free;<br />
CDDB.Free;<br />
end;<br />
end;</syntaxhighlight><br />
<br />
You can get a list of supported categories using TCDDBListCategories<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnCategoriesClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
cmd: TCDDBListCategories;<br />
begin<br />
CDDB := TCDDB.Create;<br />
cmd := TCDDBListCategories.Create(CDDB);<br />
try<br />
cmd.Execute;<br />
lbxCategories.Items.Assign(cmd.ListCategoriesResponse.Categories);<br />
finally<br />
cmd.Free;<br />
CDDB.Free;<br />
end;<br />
end;</syntaxhighlight><br />
<br />
This last example will query the database using the cdrom '/dev/cdrom'. The result is loaded into a TStringGrid named grdQueryResponse.<br />
<br />
<syntaxhighlight lang="pascal"><br />
procedure TForm1.btnQueryClick(Sender: TObject);<br />
var<br />
CDDB: TCDDB;<br />
Cmd: TCDDBQuery;<br />
i: Integer;<br />
begin<br />
CDDB := TCDDB.Create;<br />
Cmd := TCDDBQuery.Create(CDDB);<br />
try<br />
Cmd.Device := '/dev/cdrom'<br />
try<br />
Cmd.Execute;<br />
except on E:Exception do<br />
begin<br />
ShowMessage(E.Message);<br />
Exit;<br />
end;<br />
end;<br />
<br />
with Cmd.QueryResponse do<br />
begin<br />
for i := 0 to ResponseCount-1 do<br />
begin<br />
grdQueryResponse.RowCount := grdQueryResponse.RowCount+1;<br />
grdQueryResponse.Cells[0,i+1] := Artist[i];<br />
grdQueryResponse.Cells[1,i+1] := Album[i];<br />
grdQueryResponse.Cells[2,i+1] := Category[i];<br />
grdQueryResponse.Cells[3,i+1] := DiscID[i];<br />
end;<br />
end;<br />
finally<br />
cmd.Free;<br />
CDDB.Free<br />
end;<br />
end;</syntaxhighlight><br />
<br />
[[Category:Components]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Custom_Attributes&diff=140433Custom Attributes2020-10-10T10:25:03Z<p>PascalDragon: Highlight that the feature is only available in trunk right now</p>
<hr />
<div>Custom Attributes currently allow you to decorate type definitions and <br />
published properties of classes with additional metadata that can be <br />
queried using RTTI (runtime type information). <br />
<br />
'''Currently (as of October 2020) the feature is available only in FPC trunk (aka 3.3.1)'''<br />
==What can attributes be used for?==<br />
An attribute is used to associate specific metadata with a class. For example you can use an attribute to mark a class with the name of its corresponding database table,<br />
or to annotate a web service class with a string identifying its base path.<br />
<br />
==How are attributes declared?==<br />
Attributes are simply classes that descend from the new System type <br />
TCustomAttribute. The constructors of such TCustomAttribute descendants are the most important feature to implement since they are used to pass additional parameters to the attribute (such as the associated database table name, or the base path in the above examples).<br />
<br />
'''Important''': If you want to use your attribute type without any arguments then you ''must'' declare a parameterless constructor yourself as the one of ''TCustomAttribute'' is private.<br />
<br />
==How are attributes used?==<br />
<br />
Attributes are bound to a type or property by specifying at least one <br />
attribute clause ahead of the type or property. For a type the attribute is specified in the<br />
type definition (such as a class, record, or enum declaration) or in a unique <br />
type redeclaration (e.g. "TLongInt = type LongInt"). Mere type renames <br />
(e.g. "TLongInt = LongInt") are not allowed.<br />
<br />
Attribute clauses are only available if the new modeswitch <br />
PREFIXEDATTRIBUTES is set, which is the default in mode Delphi and <br />
DelphiUnicode.<br />
<br />
The syntax of an attribute clause is as follows:<br />
<br />
ATTRIBUTECLAUSE::='[' ATTRIBUTELIST ']'<br />
ATTRIBUTELIST::=ATTRIBUTE [, ATTRIBUTELIST ]<br />
ATTRIBUTE::=IDENTIFIER [ ( PARAMLIST ) ]<br />
PARAMLIST::=CONSTEXPR [, PARAMLIST ]<br />
<br />
The IDENTIFIER is the name of the attribute class. <br />
If you name the attribute class to end with "Attribute" (the case of the "attribute" suffix is immaterial) then the name may be used subsequently without the "Attribute" suffix. So TMyAttribute and TMy are equivalent alternatives in the following example:<br />
<br />
<source lang="delphi"><br />
<br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end.<br />
<br />
</source><br />
<br />
===Querying attributes===<br />
<br />
Attributes can be accessed by both the TypInfo and Rtti units.<br />
<br />
For the TypInfo unit the ways to access attributes are as follows:<br />
<br />
For types:<br />
* use the AttributesTable field in TTypeData<br />
* use GetAttributeTable on a PTypeInfo<br />
* use GetAttribute on the attribute table together with an index to get a TCustomAttribute instance<br />
<br />
For properties:<br />
* use the AttributesTable of TPropInfo<br />
* use GetAttribute on the attribute table together with an index to get a TCustomAttribute instance<br />
* use GetPropAttribute on the PPropInfo together with an index to get a TCustomAttribute instance<br />
<br />
For the Rtti unit the ways to access attributes are as follows:<br />
<br />
For types:<br />
* use GetAttributes on the TRttiType of the type in question<br />
<br />
For properties:<br />
* use GetAttributes on the TRttiProperty of the property in question<br />
<br />
==The attributes feature's compatibility with Delphi==<br />
<br />
The feature itself is Delphi compatible with the proviso that FPC is much more <br />
unforgiving regarding unbound properties. If the attribute class is not <br />
known or the attribute clauses are not bound to a valid type or property <br />
the compiler will generate an error.<br />
<br />
FPC's RTTI is not considered Delphi compatible. However it covers the <br />
same functionality. In contrast to Delphi (which uses Invoke to create the <br />
attribute instance) FPC uses a constructor function. FPC's implementation has the <br />
advantage of working on systems that don't have full Invoke support.<br />
<br />
Additionally using the PREFIXEDATTRIBUTES modeswitch disables the <br />
directive clauses for functions, methods and procedure/method types.<br />
The following is not allowed any more with the PREFIXEDATTRIBUTES modeswitch enabled:<br />
<br />
<source lang="delphi"><br />
procedure Test; [cdecl];<br />
begin<br />
end;<br />
</source><br />
== Complete example ==<br />
<source lang="Delphi">program testattributes;<br />
{<br />
This is a simple example on how to use custom attributes.<br />
The class uses a custom attribute to retrieve a static date <br />
at program start-up. This is just for the purpose of demo.<br />
This demo's:<br />
- Creation<br />
- Decoration<br />
- Retrieval<br />
}<br />
<br />
{$mode delphi}{$H+}{$M+}<br />
{$warn 5079 off} { turn warning experimental off }<br />
uses<br />
sysutils, typinfo, rtti, classes;<br />
<br />
type<br />
{A custom attribute to decorate a class with a certain date }<br />
ADateTimeAttribute = class(TCustomAttribute)<br />
private<br />
FArg:TDateTime;<br />
public<br />
{ Just to show a Custom Attribute can have mutiple constructors }<br />
constructor Create(const aArg: TDateTime);overload;<br />
{ We can use the predefined %DATE% compiler include<br />
In the context of a custom attribute we need a<br />
constant expression for the default parameter }<br />
constructor Create(const aArg: String = {$I %DATE%});overload;<br />
published<br />
property Date:TDateTime read Farg;<br />
end;<br />
<br />
{ A datetime class that is decorated with our custom attribute }<br />
{ Note you can leave out 'Attribute', the compiler resolves it }<br />
{ [ADateTime(21237.0)] uses first constructor,displays some date in 1958 }<br />
<br />
{This calls the second constructor }<br />
[ADateTime]<br />
TMyDateTimeClass = class<br />
private<br />
FDateTime:TDateTime;<br />
public<br />
constructor create;<br />
published<br />
[ADateTime]<br />
property Day:TDateTime read FDatetime write FdateTime;<br />
end;<br />
<br />
constructor ADateTimeAttribute.Create(const aArg: TDateTime);<br />
begin<br />
FArg := aArg;<br />
end;<br />
<br />
constructor ADateTimeAttribute.Create(const aArg: string );<br />
var<br />
MySettings:Tformatsettings;<br />
begin<br />
{ set up the date format according to how<br />
the compiler formats %DATE% include }<br />
MySettings :=DefaultFormatSettings;<br />
MySettings.ShortDateFormat:='yyyymmdd';<br />
MySettings.DateSeparator :='/';<br />
{ Now convert }<br />
FArg := StrToDateTime(aArg, MySettings);<br />
end;<br />
<br />
{ We query the rtti to set the value }<br />
constructor TMyDateTimeClass.Create;<br />
var<br />
Context : TRttiContext;<br />
AType : TRttiType;<br />
Attribute : TCustomAttribute;<br />
begin<br />
inherited; <br />
Context := TRttiContext.Create;<br />
try<br />
AType := Context.GetType(typeinfo(TMyDateTimeClass));<br />
for Attribute in AType.GetAttributes do begin<br />
if Attribute is ADateTimeAttribute then<br />
FDateTime := ADateTimeAttribute(Attribute).Date;<br />
end;<br />
finally<br />
Context.Free<br />
end; <br />
end;<br />
<br />
<br />
var<br />
Test:TMyDateTimeClass; <br />
begin<br />
Test := TMyDateTimeClass.Create;<br />
try<br />
writeln('Compile date is :',DateTimeToStr(Test.Day));<br />
finally<br />
test.free;<br />
end;<br />
end.</source><br />
<br />
==See Also==<br />
* [[FPC New Features Trunk]]<br />
* http://docwiki.embarcadero.com/RADStudio/XE6/en/Overview_of_Attributes - Delphi Attributes reference<br />
* http://delphi.about.com/od/oopindelphi/a/delphi-attributes-understanding-using-attributes-in-delphi.htm Delphi Tutorial on property attributes<br />
<br />
[[Category:FPC]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_3.2.0&diff=140297FPC New Features 3.2.02020-09-27T08:44:14Z<p>PascalDragon: It's not only about freestanding generic routines, but methods well</p>
<hr />
<div>== About this page ==<br />
<br />
FPC 3.2.0 has been released on June 19th, 2020.<br />
<br />
Below you can find a list of new features introduced since the [[FPC New Features 3.0|previous release]], along with some background information and examples.<br />
<br />
A list of changes that may break existing code can be found at [[User Changes 3.2]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler options ===<br />
<br />
==== Default unit scopes ====<br />
* '''Overview''': Support has been added for unit scopes (aka namespaces aka dotted units) that can be supplied by command line argument using ''-FN<x>''.<br />
* '''Notes''':<br />
** When the compiler needs to search a unit it first searches for the unit as is (first a compiled unit, then the source), then it prepends each supplied unit scope (in the supplied order) to the unit name (separated by a ''.'') and again searches for first for a compiled unit, then the source for each unit scope.<br />
** The feature is compatible with the ''-Un'' option<br />
** If unit scopes are provided they can also be left out when resolving identifiers that are part of that scope.<br />
* '''More information''': See also the announcement mail [https://lists.freepascal.org/pipermail/fpc-announce/2018-May/000605.html here]<br />
* '''svn''': r38911 - r38921, r38922<br />
<br />
=== Language ===<br />
<br />
==== Support for interfacing with C ''blocks'' functionality ====<br />
* '''Overview''': Support has been added for interfacing with [http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html Apple's ''blocks'' C-extension].<br />
* '''Notes''':<br />
** As C ''blocks'' are very similar to anonymous methods in Delphi, we use a similar syntax to declare ''block'' types (with an added ''cblock'' and either the calling convention ''cdecl'' or ''mwpascal'' to indicate the C nature). Note that the syntax to define the code executed in a ''block'' (inline, like with anonymous methods in Delphi, or in a separately defined function/method) and the functionality of a block (the ability to capture context and code to execute it at an arbitrary point in the future) are two separate things. At this time (r29594), only the code from a global function/procedure or from an Object Pascal instance/class method can be executed within the context of a ''block''. In the future, support will be added for nested functions and later probably also for code that is defined inline, like in Delphi.<br />
** This functionality is currently only supported by FPC on Mac OS X 10.7 (Lion) and later, and on iOS 4.0 and later. The reason it doesn't work on Mac OS X 10.6 (Snow Leopard) and earlier, is that we require functionality that was added to the blocks runtime in later versions.<br />
** The ''blocks'' functionality can be activated on supported platforms via ''{$modeswitch cblocks}''<br />
* '''More information''':<br />
** Example with a global procedure: http://svn.freepascal.org/svn/fpc/trunk/tests/test/tblock1.pp<br />
** Example with an Object Pascal instance method: http://svn.freepascal.org/svn/fpc/trunk/tests/test/tblock2.pp<br />
* '''svn''': r29517, r29594<br />
<br />
==== Support for Default Namespaces ====<br />
* '''Overview''': Namespaces can be supplied to the compiler to be prefixed to units that would otherwise not be found<br />
* '''Description''':<br />
** Use the new ''-FN<x>'' parameter to add a default namespace <x> to the list of default namespaces. If a unit name can not be found as-is then it will be searched for using all provided default namespaces as prefix (separated by a ".") until it is found or the list of namespaces is exhausted.<br />
** The default namespaces can also be used as prefixes for identifiers outside the ''uses'' section.<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053769.html<br />
* '''svn''': r38911 - r38922<br />
<br />
==== Dynamic Arrays supported by Insert() ====<br />
* '''Overview''': The ''Insert()'' intrinsic can be used to insert arrays and elements into an existing dynamic array.<br />
* '''Notes''':<br />
** The element to be inserted can be either of the following:<br />
***dynamic array of the same type<br />
***static array of the same type<br />
***a single element of the array's element type<br />
** The insertion index is zero based<br />
** If the dynamic array to be modified is empty it will simply contain the new data afterwards<br />
** If the index is larger than the current highest index of the array then the new data is appended at the end<br />
** If the index is negative then the new data will be appended at the start of the array<br />
** This feature is Delphi compatible with the exception of inserting static arrays which is not supported by Delphi<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== Dynamic Arrays supported by Delete() ====<br />
* '''Overview''': The ''Delete()'' intrinsic can be used to remove a sub range from an existing dynamic array.<br />
* '''Notes''':<br />
** The start index is zero based<br />
** The resulting range of ''Index'' and ''Count'' will be capped at the dynamic array's boundaries (namely 0 and the highest element); this may mean that in an extreme case no element is removed as the range is outside of the array's<br />
** This feature is Delphi compatible<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== Dynamic Arrays supported by Concat() ====<br />
* '''Overview''': The ''Concat()'' intrinsic can be used to concatenate two or more dynamic arrays together.<br />
* '''Notes''':<br />
** The resulting array will look as if all array elements had been added manually to the new array in order<br />
** Empty arrays don't contribute to the new array<br />
** This feature is Delphi compatible<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== Dynamic Arrays have built in ''+'' operator support ====<br />
* '''Overview''': The ''+'' operator can be used to concatenate two or more dynamic arrays together.<br />
* '''Notes''':<br />
** Requires new modeswitch ''ArrayOperators'' (enabled by default in Delphi modes)<br />
** The resulting array will look as if all array elements had been added manually to the new array in order<br />
** Empty arrays don't contribute to the new array<br />
** This feature is Delphi compatible<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== Dynamic Array constants and variable initialization ====<br />
* '''Overview''': Dynamic arrays constants are now possible just as well as initializing dynamic array variables during their declaration. In both cases the same syntax as for static arrays is used.<br />
* '''Notes''':<br />
** Adheres to the ''$J'' switch regarding writable constants, both for the variable itself as well as its content<br />
** Static and dynamic array constants can be nested<br />
** Delphi compatibility:<br />
*** In Delphi modes the syntax is ''[…]'' instead of ''(…)''<br />
*** Static array constants can not be used inside dynamic array constants<br />
*** Delphi does not adhere to the ''$J'' switch for the array's contents<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== Dynamic Arrays constructors ====<br />
* '''Overview''': The ''[…]'' syntax can be used to initialize dynamic array variables in code or to pass them to dynamic arrays parameters.<br />
* '''Notes''':<br />
** This feature is Delphi compatible<br />
* '''More information''': announcement mail at https://lists.freepascal.org/pipermail/fpc-pascal/2018-May/053892.html<br />
<br />
==== More settings supported by ''$Push''/''$Pop'' ====<br />
* '''Overview''': The directives ''$Push'' and ''$Pop'' now also handle the directives ''$MinEnumSize'', ''$PackSet'' and ''$PackRecords''.<br />
<br />
==== Support for ''threadvar'' sections inside class and record types ====<br />
* '''Overview''': Class and record types can now contain a ''class threadvar'' section that allows for the addition of scoped threadvar variables.<br />
* '''Notes''':<br />
** This feature is Delphi compatible<br />
** Not including the ''class'' specifier is considered an error<br />
* '''svn''': 39285 - 39289<br />
<br />
==== Support for Generic Routines ====<br />
* '''Overview''': FPC has supported the declaration of generic types and also allowed member methods to access any generic parameters their "parent" type may have for many years. Building on this, it is now possible to declare uniquely generic routines (functions, procedures, methods) either as part of structured types or globally. In the non-Delphi syntax compatibility modes they are declared with the '''generic''' keyword preceding the '''procedure''' or '''function''' keyword and specialized with the '''specialize''' keyword preceding the identifier of the generic routine when issuing a call. In mode Delphi the syntax follows that of Delphi.<br />
* '''Notes''':<br />
** This feature is Delphi-compatible, with the exception that Delphi itself does ''not'' support global (aka flat or free-standing) generic functions or procedures, only generic member methods. FPC does support them in all syntax modes (including {$mode Delphi}), however.<br />
** It's currently not possible to declare a uniquely generic method inside of an already-generic structured type. This will be changed in a future version.<br />
** It's currently not possible to take a pointer to the specialization of a generic routine.<br />
** In {$mode Delphi}, some particularly complex expressions involving multiple specializations are not yet possible.<br />
** Inlining is fully supported as long as the body of the generic routine has already been parsed.<br />
* '''Examples''':<br />
<syntaxhighlight lang="pascal"><br />
unit UTestObjFPCSyntax;<br />
<br />
{$mode ObjFPC}<br />
<br />
interface<br />
<br />
generic function Add<T>(const Arg1, Arg2: T): T;<br />
<br />
implementation<br />
<br />
generic function Add<T>(const Arg1, Arg2: T): T;<br />
begin<br />
Result := Arg1 + Arg2;<br />
end;<br />
<br />
end.<br />
</syntaxhighlight><br />
<syntaxhighlight lang="pascal"><br />
program TestObjFPCSyntax;<br />
<br />
{$mode ObjFPC}{$H+}<br />
<br />
uses<br />
UTestObjFPCSyntax;<br />
<br />
begin<br />
Writeln(specialize Add<String>('Hello', 'World'));<br />
Writeln(specialize Add<LongInt>(23, 19));<br />
end.<br />
</syntaxhighlight><br />
<syntaxhighlight lang="pascal"><br />
unit UTestDelphiSyntax;<br />
<br />
{$mode Delphi}<br />
<br />
interface<br />
<br />
function Add<T>(const Arg1, Arg2: T): T;<br />
<br />
implementation<br />
<br />
function Add<T>(const Arg1, Arg2: T): T;<br />
begin<br />
Result := Arg1 + Arg2;<br />
end;<br />
<br />
end.<br />
</syntaxhighlight><br />
<syntaxhighlight lang="pascal"><br />
program TestDelphiSyntax;<br />
<br />
{$mode Delphi}<br />
<br />
uses<br />
UTestDelphiSyntax;<br />
<br />
begin<br />
Writeln(Add<String>('Hello', 'World'));<br />
Writeln(Add<LongInt>(23, 19));<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Management operators for record types ====<br />
* '''Overview''': It is now possible to declare "management" operators inside record types which allow their built-in initialization, finalization and copying functionality to be extended. The new operators are ''Initialize'', ''Finalize'', ''Copy'' and ''AddRef''. ''Initialize'', ''Finalize'' and ''AddRef'' take the record as a '''var'''-parameter while the ''Copy'' operator takes the source record as first parameter and the destination record as second parameter whereby that one is a '''var'''-parameter. The ''Initialize'' and ''Finalize'' operators are called when such a record enters the scope or leaves it respectively. ''Copy'' is called when a record variable is assigned to another. ''AddRef'' is called when a new reference to an existing record is required which for example is the case when by-value-parameters are passed.<br />
* '''Example''': See the [[management operators]] wiki page for several code examples, as well as for more in-depth information on the feature.<br />
<br />
==== Method RTTI for interfaces ====<br />
* '''Overview''': Is the ''$M'' directive enabled when parsing an interface detailed RTTI for each method contained in the interface is generated. This information is detailed enough to not only enumerate the parameter declaration, but also to call interface functions with the help of the ''Rtti.Invoke()'' function.<br />
* '''Notes''':<br />
** The idea of the feature is Delphi compatible, however the RTTI binary data is not.<br />
** It's recommended to either use the records provided by unit ''TypInfo'' or the types provided by unit ''Rtti'' for access to avoid any problems with parsing the data.<br />
** The generation of method RTTI data is currently restricted to COM-interfaces.<br />
* '''Example''': See https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/trtti15.pp<br />
<br />
==== Support for helper types extending interface types ====<br />
* '''Overview''': A '''type helper''' can now also extend interface types. The implementations are not provided by the interface implementer, but by the helper itself.<br />
* '''Notes''': This allows to add functionality to an interface that does not depend on the implementer, but merely on the interface.<br />
* '''svn''': 37023<br />
<br />
==== Support for "IsManagedType" intrinsic ====<br />
* '''Overview''': An ''IsManagedType'' intrinsic has been added to check whether a provided type or variable/field is a managed type (currently ''AnsiString'', ''UnicodeString'', COM interface, dynamic array and record with management operators).<br />
* '''Notes''': This function returns a constant Boolean value and is Delphi compatible.<br />
* '''Examples''':<br />
** https://svn.freepascal.org/svn/fpc/trunk/tests/test/tismngd1.pp<br />
** https://svn.freepascal.org/svn/fpc/trunk/tests/test/tismngd2.pp<br />
* '''svn''': 43409<br />
<br />
==== Support for PE/COFF metadata directives ====<br />
* '''Overview''': The directives ''SetPEOSVersion'', ''SetPESubSysVersion'' and ''SetPEUserVersion'' can be used to set the corresponding fields of the PE/COFF header of the resulting binary. The format is <MAJOR>.<MINOR>.<br />
* '''Notes''':<br />
** Take care with the versions as that may lead to binaries not starting on older versions of Windows.<br />
** This is Delphi compatible.<br />
* '''Example:'''<br />
** https://svn.freepascal.org/svn/fpc/trunk/tests/tbs/tb0633.pp<br />
* '''svn''': 37364<br />
<br />
==== Support for WinAPI directive ====<br />
* '''Overview''': The directive ''WinAPI'' can be used as a calling convention for routines to use the default calling convention off the target platform. This is equivalent to using ''StdCall'' on the Windows platforms (though ''StdCall'' only has any effect on ''i386'') and ''CDecl'' on all other platforms.<br />
* '''Notes''':<br />
** Delphi compatible<br />
** Despite it's name it's not restricted to the Windows platform.<br />
* '''svn''': 29500<br />
<br />
=== Units ===<br />
<br />
==== rtl-generics units ====<br />
* '''Overview''': A new package named "rtl-generics" was added.<br />
* '''Notes''': This package contains Delphi compatible units generics.defaults, generics.collections and others, implementing, amongst others, TDictionary<>.<br />
==== Rtti unit ====<br />
* '''Overview''': A new unit named ''Rtti'' has been added which provides a high-level, object oriented access to the type information stored in the binary.<br />
* '''Notes''':<br />
** This unit is intended to be Delphi-compatible<br />
** This unit is currently experimental and not all features provided by the Delphi equivalent are yet available. Either types/methods are missing and thus compilation will fail or calling unsupported methods will trigger an exception.<br />
** The ''Invoke()'' function as well as the callback functionality for ''TMethodImplementation'' is provided by a manager which is by default not set (an ''EInvocationError'' will be raised in that case). Currently an implementation using the [http://sourceware.org/libffi/ libffi] library is provided for selected platforms for which the unit ''ffi.manager'' needs to be used in the main project file, as well as a native implementation for x86_64 Windows which does not rely on the ''ffi.manager'' unit.<br />
<br />
==== ProcessUnicode unit ====<br />
* '''Overview''': A new unit named ''ProcessUnicode'' has been added which provides an unicodestring version of TProcess. This allows unicodesupport on Windows without setting the default type to UTF-8.<br />
* '''Notes''':<br />
** Both the old and the new TProcess units were reworked. Parts of the Runcommand support are now accessible in the class and parametrized with events. This makes custom versions easier.<br />
<br />
==== Registry unit ====<br />
*'''Overview''': The TRegistry class was made to be fully Unicode capable.<br />
*'''Notes''': <br />
**All public and protected methods (the public API) that used string parameters now default to use UnicodeString parameters.<br />
**For all these methods overloads exist using String parameters (these call their UnicodeString counterparts).<br />
**Methods using TStrings have counterparts using TUnicodeStringArray, and ReadStringList/WriteStringList let you specify if the TStrings should be treated as UTF8 encoded.<br />
**The public API of TXMLRegistry was changed to use UnicodeString everywhere, without having String overloads. TXMLRegistry interfaces with a TXMLDocument structure internally, which uses DOMString (which in turn is an alias to WideString).<br />
**TRegIniFile and TRegistryIniFile have been deprecated on non-Windows platforms.<br />
**The public API of TRegIniFile has not been changed.<br />
*'''More information''': https://lists.freepascal.org/pipermail/fpc-devel/2019-February/040446.html<br />
*'''svn''': r41784<br />
<br />
==== CHM package ====<br />
<br />
*'''Overview''': The Index writing of the CHM generator was completely rewritten.<br />
*'''Notes''': The result should now be more in line with what the MS CHM compiler does. Most notably the old binary index generation sometimes seemed to drop lemmas from the helpfile, this has been resolved, and even quite large helpfiles like AGS' only have a handful of differences with the MS generated index, mostly due to changes in order/sorting.<br />
*'''More Information''': The main bugreport for the issues https://bugs.freepascal.org/view.php?id=34206 A pre 3.2.0 test snapshot is at http://www.stack.nl/~marcov/doc-chmbeta.zip containing both FPC and LCL chms.<br />
<br />
=== Text-mode IDE ===<br />
<br />
==== GDB/MI support ====<br />
* '''Overview''': GDB/MI support has been added to the text mode IDE.<br />
* '''Notes''':<br />
** It is enabled default, but can be disabled by building FPC with ''make NOGDBMI=1''<br />
** The old and deprecated libgdb.a support is still there for platforms that do not have a modern GDB port (or e.g. don't support true multitasking, like go32v2).<br />
** When debugging a console application in Windows in GDB/MI mode, the debugged program is always run in a separate console. This is due to a limitation of the Windows GDB port.<br />
* '''svn''': r30573<br />
<br />
== macOS/iOS ==<br />
<br />
=== New ''iosxwstr'' unit ===<br />
* '''Overview''': The new unit called ''iosxwstr'' can be used to install a widestring manager on macOS and iOS.<br />
* '''Notes''': The ''cwstring'' unit fulfils the same purpose, but is no longer able to provide full functionality on iOS 7 and newer due to Apple no longer shipping the locale and codepage information this unit depends on. The ''iosxwstr'' unit gets its locale information for upper/lowercase conversions from the System Preferences. Adding both ''cwstring'' and ''iosxwstr'' to the uses clause will cause the second in line to override the settings from the first one.<br />
* '''More information''': Adding this unit to the uses clause is enough to use its functionality.<br />
* '''svn''': r29828<br />
<br />
=== Cocoaint units updated ===<br />
* '''Overview''': The Cocoa Interfaces have been updated from Mac OS X 10.5 to OS X 10.10.<br />
* '''Notes''':<br />
** CoreData and QuartzCore are now part of the CocoaAll unit due to dependencies<br />
** The NSGraphicsContext.saveGraphicsState/RestoreGraphicsState methods previously mapped to the class methods with those names. They now map to the instance methods, while the corresponding class methods are called classSaveGraphicsState/classRestoreGraphicsState.<br />
* '''svn''': 42500<br />
<br />
== i8086-msdos ==<br />
<br />
=== Huge memory model ===<br />
* '''Overview''': Support has been added for the i8086 huge memory model.<br />
* '''Notes''': The huge memory model (compared to the large memory model) removes the 64kb limitation of static data for the whole program. However, there's still a 64kb limit for the static data of a single unit.<br />
* '''More information''': [[DOS#Huge|Huge memory model]]<br />
* '''svn''': r31518<br />
<br />
=== Internal assembler (object writer) ===<br />
* '''Overview''': There's an internal assembler/object writer implemented for the i8086-msdos platform. It replaces NASM and the WLIB tool.<br />
* '''Notes''': NASM is still required for building an i8086-msdos snapshot, because of the msdos startup code in the rtl. However, WLIB (from Open Watcom) is no longer required, so you can now build a fully functional smartlinked i8086-msdos snapshot from a platform that doesn't have the Open Watcom tools (such as DJGPP or macOS).<br />
* '''svn''': r30809<br />
<br />
=== Internal linker ===<br />
* '''Overview''': There's an internal linker implemented for the i8086-msdos platform. It replaces WLINK from Open Watcom.<br />
* '''Notes''': Together with the internal assembler, the internal linker removes the dependency on Open Watcom tools. NASM is still required for building an i8086-msdos snapshot, because of the msdos startup code in the rtl.<br />
* '''svn''': r31425<br />
<br />
=== FarAddr internal function ===<br />
* '''Overview''': There's a new i8086-specific internal function, similar to Addr(), called FarAddr(), which always returns a far pointer to the address of its argument.<br />
* '''Notes''': The built-in Addr() function and the @ operator return a pointer type (near or far), that depends on the memory model. When interfacing with DOS, BIOS and other 16-bit APIs, it is sometimes useful to be able to obtain a far pointer to a pascal variable or procedure/function, regardless of the selected memory model. Previously, you would have to use ifdefs, or do something like Ptr(Seg(x), Ofs(x)). Now, this can be replaced with the much nicer FarAddr(x).<br />
* '''svn''': r37629<br />
<br />
=== Near and far procedure variables ===<br />
* '''Overview''': Support has been added for procedure variables with an explicitly specified ''near'' or ''far'' call model.<br />
* '''Notes''': By default, procedure variables follow the default call model of the current memory model - ''near'' in the ''tiny'', ''small'' and ''compact'' memory models; ''far'' in the ''medium'', ''large'' and ''huge'' models. However, now you can specify an explicit ''near'' or ''far'' call model, regardless of the default for the current memory model. Note that ''near'' and ''far'' procedure variables are not compatible with each other. Syntax is really simple:<br />
type<br />
TFarProc = procedure(a, b: Integer); far;<br />
TNearProc = procedure(a, b: Integer); near;<br />
Near procedure variables are 2 bytes long, so they contain only an offset. They are invoked with a near ''call'' instruction. Far procedure variables are 4 bytes long (16-bit offset + 16-bit offset) and are invoked with a far ''call''. Note that you cannot simply convert a near procedure to a far procedure, by just filling in the segment part, because the call model is also different between near and far procedures. A far call instruction pushes a 4-byte far (segment:offset) return address and the function must terminate with a far return instruction - ''retf''. A near call instruction pushes only a 2-byte offset on the stack and the function must terminate with a near return instruction - ''retn''.<br />
* '''svn''': r38691<br />
<br />
== i386-go32v2 ==<br />
<br />
<br />
=== A new archive was added that contains alternative builds of the textmode IDE. ===<br />
* '''Overview''': A new archive was added that contains alternative builds of the textmode IDE. <br />
* '''Notes''': Various compilation options like various GDB options and without VESA support (VESA builds have problems with some windows drivers, but having VESA support is beneficial for debugging Graph applications under pure dos). The archive is available via FTP: [ftp://ftp.freepascal.org/fpc/dist/3.2.0/i386-go32v2/separate/idedos_alternative_builds.zip IDE alternative builds](60MB) containing:<br />
* '''svn''': - (release building only)<br />
* '''Contents''':<br />
<br />
** 73878497 fpgdb771novesa.exe<br />
** 74100535 fpgdb771vesa.exe<br />
** 7921184 fpgdbnovesa.exe<br />
** 22462112 fpnogdb.exe<br />
** 22378419 fpnogdbnovesa.exe<br />
** 4178288 fpnovesa.exe<br />
** 3900928 fp-ori.exe<br />
** 4240912 fpvesa.exe<br />
<br />
== i386-win32 ==<br />
<br />
=== The i386-win32 target now defaults to using SEH compatible exceptions ===<br />
* '''Overview''': The i386-win32 target now defaults to using SEH compatible exceptions.<br />
* '''Notes''': This improves compatibility with MSVC++ exception handling. <br />
* '''svn''': 43978<br />
<br />
== x86_64-win64 ==<br />
<br />
=== Support for Microsoft's vectorcall calling convention ===<br />
* '''Overview''': Under x86_64 (not i386), support for the "vectorcall" calling convention is now possible on Windows targets by specifying the '''vectorcall''' modifier.<br />
* '''Notes''': Utilises the XMM registers better than the default Microsoft ABI, allowing aligned arrays of Singles and Doubles to be passed in a single register akin to the System V ABI as used by Linux and other OS's. Also allows projects to interface with external libraries that use the convention. "vectorcall" is silently ignored if the target is not x86_64-win64.<br />
* '''svn''': 38206<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for the AArch64 target ===<br />
<br />
* '''Overview''': Support has been added for the AArch64 architecture, with Darwin (iOS), Linux, and Android as available operating system targets.<br />
* '''Notes''': Apple's A7 CPU (and potentially other AArch64 CPUs too) does not support raising a signal when a floating point exception occurs.<br />
* '''More information''': https://lists.freepascal.org/pipermail/fpc-devel/2015-February/035524.html<br />
* '''svn''': r29986 (Darwin/iOS), r30897 (Linux), r39862 ([[Android]])<br />
<br />
=== Support for the Linux/ppc64le target ===<br />
<br />
* '''Overview''': Support has been added for the Linux/ppc64le target. This is a PowerPC64 little endian platform that uses a new ABI termed ELFv2.<br />
* '''Notes''': It is not easy to build this target on a big endian Linux/ppc64 target, due to the fact that the build system does not yet contain support to deal with different ABIs/endianess.<br />
* '''More information''': To cross-compile a ppc64le compiler, use CROSSOPT="-Cb- -Caelfv2". Those options don't have to be specified when compiling on a ppc64le system using a native ppcppc64, as they will be set by default for that compiler.<br />
* '''svn''': r30228<br />
<br />
=== Support for the Android/x86_64 target ===<br />
<br />
* '''Overview''': Support has been added for the Android/x86_64 target.<br />
* '''More information''': [[Android]].<br />
* '''svn''': r39956<br />
<br />
=== Support for the i8086-win16 (16-bit Windows) target ===<br />
<br />
* '''Overview''': Experimental support has been added for the 16-bit Windows target. It is a cross compiler only target (cross compilation is possible from e.g. Win32, Win64 or Linux).<br />
* '''Notes''': Windows 3.0 or later is supported.<br />
* '''More information''': [[Win16]]<br />
<br />
== New Features from other versions ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC 3.0+ stuff]]<br />
[[Category: FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=140199FPC New Features Trunk2020-09-19T21:21:05Z<p>PascalDragon: Documented array constructor for static arrays</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Array constructors for static arrays ====<br />
* '''Overview''': Array constructors can be used to assign values to static arrays.<br />
* '''Notes''':<br />
** The array constructor needs to have the same amount of elements as the static array.<br />
** The first element of the array constructor will be placed at the location of the first element of the static array (e.g. if the array starts at -1 the first element will be at that location).<br />
** Arrays with enumeration index are supported as well.<br />
* '''svn''': 46891, 46901<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tarrconstr16.pp<br />
<br />
=== Units ===<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented.<br />
* '''Notes''': Delphi compatibile, currently implemented for Windows, Linux and Android. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 45160, 45206, 45233<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the sure changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for macOS/AArch64 ===<br />
* '''Overview''': The compiler can now target macOS running on AArch64<br />
* '''Notes''': The Darwin/AArch64 target corresponds to macOS/AArch64. Generating code for iOS/AArch64 requires a [[User_Changes_Trunk#The_Darwin_targets_corresponding_to_iOS_have_been_renamed_to_iOS|different command line parameter]] compared to previous versions.<br />
* '''More information''': [[macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support|Build instructions]]<br />
* '''svn''': 45762<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=140197FPC New Features Trunk2020-09-19T20:07:49Z<p>PascalDragon: Documented that Copy can be used with Open Array parameters</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''':<br />
** Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
** Accesses to fixed absolute addresses (as common on DOS and embedded platforms) are automatically marked as volatile by the compiler.<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
==== Copy supports Open Array parameters ====<br />
* '''Overview''': The ''Copy'' intrinsic can now be used to copy (a part of) the contents of an open array parameter to a dynamic array.<br />
* '''Notes''':<br />
** The result of the ''Copy'' function will have the type of a dynamic array with the same element type as the parameter that is copied from.<br />
** If the ''Start'' parameter is out of range the resulting dynamic array will be empty.<br />
** If the ''Count'' parameter is too large then the resulting dynamic array will only contain the elements that exist.<br />
* '''svn''': 46890<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
procedure Test(aArg: array of LongInt);<br />
var<br />
arr: array of LongInt;<br />
begin<br />
arr := Copy(aArg, 3, 5);<br />
end;<br />
</syntaxhighlight><br />
<br />
=== Units ===<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented.<br />
* '''Notes''': Delphi compatibile, currently implemented for Windows, Linux and Android. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 45160, 45206, 45233<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the sure changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for macOS/AArch64 ===<br />
* '''Overview''': The compiler can now target macOS running on AArch64<br />
* '''Notes''': The Darwin/AArch64 target corresponds to macOS/AArch64. Generating code for iOS/AArch64 requires a [[User_Changes_Trunk#The_Darwin_targets_corresponding_to_iOS_have_been_renamed_to_iOS|different command line parameter]] compared to previous versions.<br />
* '''More information''': [[macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support|Build instructions]]<br />
* '''svn''': 45762<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=139917User Changes Trunk2020-09-04T15:41:59Z<p>PascalDragon: Documented prohibition of overloads that only differed in result type</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Property field access lists no longer allows classes ====<br />
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.<br />
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.<br />
* '''Reason''':<br />
** Delphi compatibility<br />
** This resulted in an internal error for published properties<br />
* '''Remedy''':<br />
** Switch the fields to records or objects<br />
** Use a method with inline modifier that will result in similar performance<br />
* '''svn''': 40656<br />
* '''Example''': The following code now fails:<br />
<syntaxhighlight lang="pascal"><br />
unit Test;<br />
{$mode objfpc}<br />
<br />
interface<br />
<br />
type<br />
TTest1 = class<br />
Field: String;<br />
end;<br />
<br />
TTest2 = class<br />
private<br />
fTest1: TTest1;<br />
public<br />
property Prop: String read fTest1.Field; // Error "Record or object type expected"<br />
end;<br />
<br />
implementation<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' a<br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Range checking for enumeration constants in Delphi mode ====<br />
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.<br />
* '''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.<br />
* '''Reason''': Delphi-compatibility.<br />
* '''Remedy''': Fix the range errors.<br />
* '''svn''': 42272, 42275<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
==== Additional ${include %xxx%} directives ====<br />
* '''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. <br />
* '''New behaviour:''' The {$include %xxx%} directive now recognizes these additional internal variables:<br />
** <syntaxhighlight lang="pascal" inline>{$include %currentRoutine%}</syntaxhighlight> expands to the name of the current routine ([[string]]).<br />
** <syntaxhighlight lang="pascal" inline>{$include %dateYear%}</syntaxhighlight> expands to the year number at time of compilation ([[Smallint|smallInt]]).<br />
** <syntaxhighlight lang="pascal" inline>{$include %dateMonth%}</syntaxhighlight> expands to the day number in month at time of compilation ([[Shortint|shortInt]]).<br />
** <syntaxhighlight lang="pascal" inline>{$include %timeHour%}</syntaxhighlight> expands to the number of seconds at time of compilation ([[Shortint|shortInt]]).<br />
** <syntaxhighlight lang="pascal" inline>{$include %timeMinute%}</syntaxhighlight> expands to the number of minutes at time of compilation ([[Shortint|shortInt]]).<br />
** <syntaxhighlight lang="pascal" inline>{$include %timeSecond%}</syntaxhighlight> expands to the number of seconds at time of compilation ([[Shortint|shortInt]]).<br />
* '''Reason:''' Adds to the existing {$include %fileName%}, {$include %line%} and {$include %date%} directives and is handy for debugging. <br />
* '''Remedy:''' You can no longer name and use environment variable expansion with any of these names.<br />
* '''svn:''' 30873 (current routine), 38329 (date and time)<br />
<br />
==== Routines that only differ in result type ====<br />
* '''Old behaviour:''' It was possible to declare routines (functions/procedures/methods) that only differ in their result type.<br />
* '''New behaviour:''' It is no longer possible to declare routines that only differ in their result type.<br />
* '''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).<br />
* '''Remedy:''' Correctly declare overloads.<br />
* '''Notes:'''<br />
** As the JVM allows covariant interface implementations such overloads are still allowed inside classes for the JVM target.<br />
** Operator overloads (especially assignment operators) that only differ in result type are still allowed.<br />
* '''svn:''' 45973<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
== Darwin/iOS ==<br />
=== The Darwin targets corresponding to iOS have been renamed to iOS ===<br />
* '''Old behaviour:''' The Darwin/ARM and Darwin/AArch64 (ARM64) targets generated code for iOS running on those architectures.<br />
* '''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)<br />
* '''Reason for change:''' The switch of the macOS platform to AArch64 <br />
* '''svn''': 45762<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_3.2.0&diff=139625User Changes 3.2.02020-08-25T07:09:30Z<p>PascalDragon: Documented that TStringStream now derives from TBytesStream</p>
<hr />
<div>== About this page==<br />
<br />
Listed below are intentional changes made to the FPC compiler (3.2) since the [[User_Changes_3.0.4|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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_3.2|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Usage Changes ===<br />
<br />
==== Library search directories and custom sysroots ====<br />
* '''Old behaviour''': When specifying a custom sysroot (-XR), all library search directories (both built-in and specified via options) were relative to this sysroot<br />
* '''New behaviour''': Library search directories are only relative to the sysroot if they start with "=".<br />
* '''Reason''': Allow specifying custom search directories for libraries outside a sysroot.<br />
* '''Remedy''': Add "=" at the start of library search paths if you wish them to be relative to any specified sysroot.<br />
* '''Example''':<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl=/opt/X11/lib''': will search for libraries in '''/Data/Developer/MacOSX10.4u.sdk/opt/X11/lib'''<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl=/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
* '''svn''': 43279, 43302, 43306, 43312<br />
<br />
==== Additional <syntaxhighlight lang="pascal" inline>{$include}</syntaxhighlight> variables ====<br />
; Overview<br />
: The [[$include|<syntaxhighlight lang="pascal" inline>{$include}</syntaxhighlight>]] directive now recognizes the additional internal variables<br />
:* <syntaxhighlight lang="pascal" inline>{$include %currentRoutine%}</syntaxhighlight><br />
:* <syntaxhighlight lang="pascal" inline>{$include %dateYear%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %dateMonth%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %dateDay%}</syntaxhighlight><br />
:* <syntaxhighlight lang="pascal" inline>{$include %timeHour%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %timeMinute%}</syntaxhighlight>, <syntaxhighlight lang="pascal" inline>{$include %timeSecond%}</syntaxhighlight><br />
; Remedy<br />
: You cannot name and use environment variable expansion with any of those names.<br />
; svn<br />
: 30873 (current routine), 38329 (date and time)<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Dynamic array parameters are passed like pointers ====<br />
* '''Old behaviour''': When using the default calling convention, dynamic array parameters were passed on the stack.<br />
* '''New behaviour''': When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).<br />
* '''Reason''': Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.<br />
* '''Remedy''': Adjust pure assembler routines that have dynamic array parameters.<br />
* '''svn''': 30870, 30878, 31622<br />
<br />
==== VMT Interface table uses private variable FPC_EMPTYINTF ====<br />
* '''Old behaviour''': The vIntfTable field has three possible values: <br />
**Nil if the class doesn't implement any interface (but an ancestor might)<br />
**A pointer to an interface table (with count <> 0) if the class implements any interface<br />
**A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface<br />
* '''New behaviour''': The vIntfTable field has two possible values:<br />
**Nil if neither the class nor any ancestor implements an interface<br />
**A pointer to an interface table in any other case<br />
* '''Reason''': FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems<br />
* '''Remedy''': Adjust code accordingly<br />
* '''svn''': 34087<br />
<br />
==== Modeswitch ''TypeHelpers'' in Delphi modes enables ''type helper''-syntax ====<br />
* '''Old behaviour''': The modeswitch ''TypeHelpers'' is enabled by default in Delphi modes and allows to extend primitive types with ''record helper'' types.<br />
* '''New behaviour''':<br />
**The modeswitch is no longer set by default.<br />
**Primitive types can always be extended by record helpers in Delphi modes.<br />
**The modeswitch enables the ''type helper''-syntax as known from non-Delphi modes.<br />
* '''Reason''': The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.<br />
* '''Remedy''': The only problems arise if one disabled the modeswitch on purpose which now no longer disallows the extension of primitive types.<br />
* '''svn''': 37225<br />
<br />
==== Class references in a class VMT's field table ====<br />
* '''Old behaviour''': The class array of the vFieldTable of the VMT contains an array of TClass entries<br />
* '''New behaviour''': The class array of the vFieldTable of the VMT contains an array of PClass entries<br />
* '''Reason''': As for the RTTI the indirect references are necessary for dynamic packages.<br />
* '''Remedy''': Use an additional dereferentiation to access the class type.<br />
* '''svn''': 37485<br />
<br />
=== Language Changes ===<br />
<br />
==== Visibility of generic type parameters ====<br />
* '''Old behaviour''': Type parameters of generics had ''public'' visibility.<br />
* '''New behaviour''': Type parameters of generics now have ''strict private'' visibility.<br />
* '''Reason''': With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [http://bugs.freepascal.org/view.php?id=25917 this] bug report). Also the fix is Delphi compatible.<br />
* '''Remedy''': Declare a type alias for the type parameter with the desired visibility.<br />
* '''Example''': In the following example ''T'' is declared as ''strict private'', while ''TAlias'' is declared as ''public'' and thus can be used as before the change.<br />
<syntaxhighlight lang="pascal"><br />
type<br />
generic TTest<T> = class<br />
public type<br />
TAlias = T;<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Parsing of ''specialize'' has been changed ====<br />
* '''Old behaviour''': ''specialize'' was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.<br />
* '''New behaviour''': ''specialize'' is now considered part of the specialized type, just as ''generic'' is. This means that unit names and parent types need to be used before the part containing the ''specialize''.<br />
* '''Reason''': This allows for a more logical usage of ''specialize'' in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.<br />
* '''Remedy''': Put the ''specialize'' directly in front of the type which needs to be specialized.<br />
<br />
==== Operator overload ''+'' no longer allowed for dynamic arrays ====<br />
* '''Old behaviour''': The ''+'' operator could be overloaded for dynamic array types.<br />
* '''New behaviour''': The ''+'' operator for dynamic array types can no longer be overloaded if the modeswitch ''ArrayOperators'' is active (default in Delphi modes).<br />
* '''Reason''': When the modeswitch ''ArrayOperators'' is active a ''+'' operator is now provided by the compiler itself which concatenates two arrays together.<br />
* '''Remedy''':<br />
** Disable the modeswitch (for Delphi modes this can be done with ''{$modeswitch ArrayOperators-}'').<br />
** If your operator merely concatenates two arrays then remove the overload.<br />
** If your operator does something different or more then use a different operator.<br />
* '''Note''': A warning is provided by the compiler if an overload is in scope, but not used due to the internal operator.<br />
<br />
==== Generic type parameters need to match ====<br />
* '''Old behaviour''': When defining the method of a generic class or record it was possible to use different names for the type parameters than those that were used in the declaration.<br />
* '''New behaviour''': The order and name of generic type parameters of the class or record type in the method definition has to match the order and name of generic types parameters of the class or record declaration.<br />
* '''Reason''': To avoid the user making mistakes e.g. when the order of parameters is swapped. Also this is compatible to at least newer Delphi versions.<br />
* '''Remedy''': Use the correct generic type parameters for the definition.<br />
* '''svn''': 39701<br />
<br />
==== Visibility of methods implementing interface methods ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces<br />
* '''New behaviour''': Only methods visible in the class that is declared as implementing the method are considered.<br />
* '''Reason''': The symbol visibility rules should be respected in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Make (strict) private methods that should implement interface methods in descendant classes protected or public.<br />
* '''svn''': 40645<br />
<br />
==== Methods implementing interface methods and overloads ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces.<br />
* '''New behaviour''': In case of overloads, searching stops when a method is found that has the right name but not the ''overload'' directive. Note that this directive is automatically inherited when overriding a method.<br />
* '''Reason''': The same happens when calling a method, and the symbol resolution rules should be the same in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Add an ''overload'' directive to methods of which all overloads should be visible in the entire class hierarchy.<br />
* '''Example''':<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw27349.pp?r1=40683&r2=40682&pathrev=40683 Bug found by this change] (previously, on non-Windows platforms the '''_Addref''' method of ''TInterfacedObject'' was selected for implementing by the classes implementing ''tmyintf'').<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbf/tb0267.pp?view=markup Example that no longer compiles].<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbs/tb0654.pp?view=markup Fixed example].<br />
* '''svn''': 40683<br />
<br />
==== Objective-C "Related Result Type" ====<br />
* '''Old behaviour''': The type checking system always evaluated calls to Objective-C methods as them returning the declared result type.<br />
* '''New behaviour''': The type checking system now takes into account the [http://releases.llvm.org/8.0.0/tools/clang/docs/LanguageExtensions.html#objective-c-features "related result type"] rule from Objective-C. This means that certain methods are now assumed to always return an instance whose type is compatible with the object to which the message was sent (i.e., it's the same, or inherits from it). This is done for the following methods, provided their declared result type is also compatible with the class type in which the method is declared:<br />
** instance methods whose first lower case word in the message name is ''init'' or ''new''<br />
** class methods whose first lower case word in the message name is ''autorelease'', ''init'', ''retain'', or ''self''<br />
* '''Reason''': Compatibility with translations of more recent versions of Cocoa headers<br />
* '''Remedy''': Normally this should not break existing, correct code. If it does, you can probably fix it by removing superfluous typecasts.<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
{$modeswitch objectivec1}<br />
<br />
type<br />
FPCMyType = objcclass<br />
function init: id; message 'init';<br />
class function alloc: FPCMyType; message 'initWithValue';<br />
// since ObjCBool is not related to FPCMyType, the "related result type" rule will not apply here<br />
// even though the message starts with "retain" and it's a class method<br />
class function retainCounting: ObjCBool; message 'retainCounting';<br />
end;<br />
<br />
...<br />
<br />
var<br />
a: NSArray;<br />
begin<br />
// will give an error even though FPCMyType returns 'id', because 'id' is related to<br />
// FPCMyType and hence the compiler will now interpret the 'init' message as returning<br />
// an "FPCMyType" when called. Do note that the actual return type of "init" remains<br />
// "id" in all other contexts, e.g. when deciding override compatibility. The declaration<br />
// of that method is not modified, and the only changed behviour is that when calling it<br />
// the result type is statically assumed to be of FPCMyType.<br />
a:=FPCMyType.alloc.init;<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': r42816<br />
<br />
=== RTTI changes ===<br />
<br />
==== RTTI for Interfaces (published property count) ====<br />
* '''Old behavior''': The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count. <br />
* '''New behavior''': Before the property RTTI data is now a Word count field that specifies the amount of properties<br />
* '''Reason''': Both user request and usability.<br />
* '''Remedy''': Adjust pointer offsets accessing the property data accordingly.<br />
<br />
==== RTTI for COM Interfaces (IID String) ====<br />
* '''Old behavior''': COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.<br />
* '''New behavior''': The undocumented field has been removed.<br />
* '''Reason''': The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.<br />
* '''Remedy''': Use the GUID field and convert that to a String.<br />
<br />
==== RTTI Binary format change ====<br />
* '''Old behavior''': References to other types are designated by PTypeInfo.<br />
* '''New behavior''': References to other types are designated by PPTypeInfo.<br />
* '''Reason''': While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.<br />
* '''Remedy''': If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.<br />
* '''Note''': <br />
**The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.<br />
**This does not apply to TObject.ClassInfo which still returns a PTypeInfo<br />
<br />
==== RTTI for Corba Interfaces (IID String) ====<br />
* '''Old behavior''': IIDStr is a field of TTypeData.<br />
* '''New behavior''': IIDStr is a property of TTypeData.<br />
* '''Reason''': The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.<br />
* '''Remedy''': If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.<br />
* '''svn''': 35026<br />
<br />
==== Reference to Record Init Information ====<br />
* '''Old behavior''': Field RecSize follows directly after start of TTypeData record.<br />
* '''New behavior''': Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).<br />
* '''Reason''': With the record init information one can more quickly decide whehther a record needs to be classed as ''managed'' or not which is among others useful for the IsManaged() function of the Rtti unit.<br />
* '''Remedy''': If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.<br />
* '''Note''': The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.<br />
* '''svn''': 35125, 35134<br />
<br />
==== TOrdType extended ====<br />
* '''Old behavior''': TOrdType contains entries for 8-, 16- and 32-bit widths.<br />
* '''New behavior''': TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.<br />
* '''Reason''': Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.<br />
* '''Remedy''': Adjust arrays that have TOrdType as index.<br />
* '''svn''': 35135<br />
<br />
==== New OrdType field for tkInt64 and tkQWord ====<br />
* '''Old behavior''': MinInt64Value and MinQWordValue follow directly after start of TTypeData record.<br />
* '''New behavior''': MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.<br />
* '''Reason''': To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.<br />
* '''Remedy''': If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.<br />
* '''svn''': 35135<br />
<br />
==== First field of TProcedureParam changed ====<br />
* '''Old behavior''': First field of TProcedureParam is called Flags and has type Byte.<br />
* '''New behavior''': First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.<br />
* '''Reason''': Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.<br />
* '''Remedy''': Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.<br />
* '''svn''': 35174<br />
<br />
==== TParamFlag extended for constref ====<br />
* '''Old behavior''': TParamFlag has no entry for constref parameters.<br />
* '''New behavior''': TParamFlag has entry pfConstRef for constref parameters.<br />
* '''Reason''': To correctly detect constref parameters they need to be marked accordingly.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).<br />
* '''svn''': 35175<br />
<br />
==== Ranges of Boolean types adjusted ====<br />
* '''Old behavior''': ByteBool, WordBool and LongBool have a range of 0..-1.<br />
* '''New behavior''': ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).<br />
* '''Reason''': The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.<br />
* '''Remedy''': Adjust code that might have relied on the range being ''invalid''.<br />
* '''svn''': 35184<br />
<br />
==== OrdType of Boolean64 and QWordBool adjusted ====<br />
* '''Old behavior''': Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.<br />
* '''New behavior''': Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.<br />
* '''Reason''': Both types have a size of 64-bit thus using a smaller size is incorrect.<br />
* '''Remedy''': Use the correct fields to retrieve the range boundaries of the types.<br />
* '''svn''': 35185<br />
<br />
==== All Boolean types have TypeKind tkBool ====<br />
* '''Old behavior''': Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.<br />
* '''New behavior''': Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.<br />
* '''Reason''': Consistency and possibility to differentiate ordinary subranges from the real Boolean types.<br />
* '''Remedy''': Check for TypeKind tkBool instead of some "magic" to detect Boolean types.<br />
* '''Note''': Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.<br />
* '''svn''': 35186, 35187<br />
<br />
==== TParamFlag extended for hidden parameters ====<br />
* '''Old behavior''': TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1<br />
* '''New behavior''': TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2<br />
* '''Reason''': As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).<br />
* '''svn''': 35267, 35286, 35291<br />
<br />
==== Parameters of method pointer variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of method pointer variables only listed visible parameters.<br />
* '''New behavior''': The parameters of method pointer variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
==== Parameters of procedure variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of procedure variables only listed visible parameters.<br />
* '''New behavior''': The parameters of procedure variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
=== Unit changes ===<br />
<br />
==== SysUtils ====<br />
<br />
===== faSymlink =====<br />
* '''Old behaviour:''' faSymlink had the numerical value $40. This was wrong on windows, and not compatible with Delphi.<br />
* '''New behaviour:''' faSymlink has the numerical value $400. Correct on windows.<br />
* '''Reason for change:''' Wrong functionality and Delphi compatibility.<br />
* '''Remedy:''' If you are using the old numerical constant $40, simply use faSymlink instead.<br />
* '''svn:''' r33340<br />
<br />
===== FileExists on Unix-based systems =====<br />
* '''Old behaviour:''' ''FileExists'' returns ''True'' for existing directories.<br />
* '''New behaviour:''' ''FileExists'' does not return ''True'' for existing directories.<br />
* '''Reason for change:''' Directories are not files, thus it was illogical for ''FileExists'' to return ''True'' for existing directories. Also this brings it in line with Windows and Delphi.<br />
* '''Remedy:''' Use ''DirectoryExists'' to check for the existance of a directory<br />
* '''svn:''' r43111<br />
<br />
==== Classes.TList auto-growth ====<br />
* '''Old behaviour:''' Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity<br />
* '''New behaviour:''' Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.<br />
* '''Reason for change:''' Avoid out-of-memory when very large lists are expanded<br />
* '''svn:''' 34462<br />
<br />
==== Math Min/Max ====<br />
* '''Old behaviour:''' Mixing of QWord and Int64 was possible as there was no QWord overload. However the result might have been wrong.<br />
* '''New behaviour:''' Overload for QWord exists now but mixed calls with Int64/QWord cause a compiler error.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Apply an explicit typecast to one of the parameters so both are of the same type.<br />
* '''svn:''' 39995<br />
<br />
==== StrUtils AnsiStartsText/AnsiEndsText ====<br />
* '''Old behaviour:''' AnsiStartsText or AnsiEndsText would return false for empty substring. This is not in line with Delphi, which returns true.<br />
* '''New behaviour:''' AnsiStartsText or AnsiEndsText now return True for empty substring.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Check explicitly for empty string if you counted on the old behaviour.<br />
* '''svn:''' 38768<br />
<br />
==== Types IStream interface and Classes TStreamAdapter ====<br />
* '''Old behaviour:''' IStream Interface (classes unit and jwa units) used Int64 for various out parameters.<br />
* '''New behaviour:''' IStream Interface (classes unit and jwa units) use QWord for various out parameters.<br />
* '''Reason for change:''' The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.<br />
* '''Remedy:''' If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.<br />
* '''svn:''' 32820 and 35542<br />
<br />
==== Baseunix (Linux only) ====<br />
* '''Old behaviour:''' stat was an union, with one side the proper posix fieldnames, and the other deprecated, simplified 1.0.x fieldnames. The 1.0.x were already marked as deprecated for 2 major cycles.<br />
* '''New behaviour:''' Deprecated 1.0.x fieldnames removed.<br />
* '''Reason for change:''' Left over 1.0.x transition feature. Incompatible with other *nix ports. <br />
* '''Remedy:''' Update fieldnames <br />
* '''svn:''' 39644 and 39655<br />
<br />
==== Classes TStrings.LoadFromStream/File encoding handling ====<br />
* '''Old behaviour:''' The LoadFromStream call totally ignored the encoding of a file, loading it from a stream without regard for encoding, unless an encoding was specified. <br />
* '''New behaviour:''' There is an overloaded call with a Boolean parameter 'IgnoreEncoding' which determines whether the encoding should be taken into account or not. By default, this parameter is False, meaning that LoadFromStream with just a stream as argument now calls the encoding-aware version of LoadFromStream, passing it an encoding of Nil, which mean the default encoding will be used.<br />
* '''Reason for change:''' Delphi compatibility, and the corresponding changes in TStringStream constructors.<br />
* '''Remedy:''' The old behaviour can be restored by setting the IgnoreEncoding parameter to 'True'.<br />
* '''svn:''' 37962 and 37965<br />
<br />
===== TStringStream now observes system encoding =====<br />
* '''Old behaviour''': TStringStream copied bytes as-is from the string specified in the constructor. <br />
* '''New behaviour''': Now bytes are fetched from the string using the encoding of the string.<br />
* '''Reason:''' Delphi-compatibility<br />
* '''Remedy:''' Pass a string with the correct encoding to TStringStream<br />
* '''svn''': 36758<br />
<br />
===== TStringStream derives from TBytesStream =====<br />
* '''Old behaviour''': ''TStringStream'' is derived from TStream.<br />
* '''New behaviour''': ''TStringStream'' is derived from ''TBytesStream'' which in turn derives from ''TMemoryStream''.<br />
* '''Reason:'''<br />
** needed for the above mentioned observing of the system encoding<br />
** Delphi-compatibility<br />
* '''Remedy:''' You need to adjust checks for inheritance.<br />
* '''svn''': 36758<br />
<br />
==== DB ====<br />
===== TParam.LoadFromFile sets share mode to fmShareDenyWrite =====<br />
* '''Old behaviour''': TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file<br />
* '''New behaviour''': TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file<br />
* '''Remedy''': If your application requires exclusive access to file specify fmShareExclusive<br />
<br />
===== CodePage aware TStringField and TMemoField =====<br />
* '''Old behaviour''': These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.<br />
* '''New behaviour''': When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.<br />
<br />
===== ODBC headers on Unix platforms defaults to 3.52 version =====<br />
* '''Old behaviour''': default was ODBCVER $0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.<br />
* '''New behaviour''': default is ODBCVER $0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).<br />
<br />
===== TBlobData opaque type reworked to TBytes =====<br />
* '''Old behaviour''': TBlobData was declared as Ansistring<br />
* '''New behaviour''': TBlobData is declared as TBytes <br />
* '''Reason for change''': Delphi compatibility. Also helps to avoid possible code page recodings.<br />
* '''Remedy''': If your application used TBlobData as a string, you can use AsString for parameters, or convert to TBytes.<br />
<br />
==== FGL ====<br />
===== Declaration of type TTypeList changed =====<br />
* '''Old behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''array[0..GMaxListSize] of T''.<br />
* '''New behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''PT''.<br />
* '''Reason''': The way ''GMaxListSize'' was declared this could lead to too large static array types so that compilation aborted with a ''Data segment too large'' error. This also might have lead to incorrect range errors if range checking was turned on. As FPC supports indexed access to pointer types potential type problems when using the ''List'' property should be minimal.<br />
* '''Remedy''': If your application relies on ''PTypeList'' to be a static array type (instead of merely being indexable like an array) then you'll need to adjust your code.<br />
* '''svn''': 39464<br />
<br />
==== objcbase ====<br />
* '''Old behaviour''': The Objective-C BOOL type was represented by objcbase.BOOL, which was the same as a Pascal boolean on all platforms.<br />
* '''New behaviour''': The Objective-C BOOL type is now represented by objcbase.ObjCBOOL, which maps to a boolean type that always corresponds to the one used in Objective-C (it differs on some platforms)<br />
* '''Reason''': The renaming was to prevent name clashes, and the type definition change was to fix interfacing issues between Objective-Pascal and Objective-C<br />
* '''Remedy''': change all uses of Boolean and BOOL in Objective-Pascal method definitions to ObjCBool.<br />
* '''svn''': 42483<br />
<br />
==== SimpleIPC ====<br />
* '''Old behaviour''': ReadMessage is a procedure.<br />
* '''New behaviour''': ReadMessage is a function, returning a boolean, telling you whether a message was actually read.<br />
* '''Reason''': Provide more information to the user. <br />
* '''Remedy''': Handle the result if necessary. (if you used OnMessage, no change is necessary)<br />
* '''svn''': 36916<br />
<br />
<br />
==== Process Unit ====<br />
<br />
===== Runcommand =====<br />
* '''Old behaviour:''' Runcommand had a few short sleeps to reduce CPU usage when the called process ran long.<br />
* '''New behaviour:''' Runcommand defaults to no sleep unless poRunIdle is passed to the default parameter with process options.<br />
* '''Reason for change:''' Applications that ran binaries to quickly obtain information were stalled by the pauses for no good reason. Servicing both short and long running binaries adequately without additional info seemed impossible due to slightly differing OS behaviours in pipe reading.<br />
* '''Remedy:''' For short living processes that start up quickly: do nothing. For long running processes, pass poRunIdle as process option.<br />
* '''svn:''' this changes was merged post RC1<br />
<br />
===== pnoconsole on Windows =====<br />
* '''Old behaviour:''' On Windows, ponoconsole mapped to winapi DETACH_PROCESS which still created standard input/output/error handles.<br />
* '''New behaviour:''' ponewconsole maps to CREATE_NO_WINDOW, which doesn't create input/output/error handles. A new option podetached allows for DETACH_PROCESS<br />
* '''Reason for change:''' ponoconsole still created a window in cases. (mantis [https://bugs.freepascal.org/view.php?id=32055 bug 32055]). <br />
* '''Remedy:''' If you try to hide the console but still need stdin/stdout handles, then ponoconsole no longer works. You could try podetached. See also [https://forum.lazarus.freepascal.org/index.php/topic,49631.msg360286.html#msg360286 podetached forum thread]<br />
* '''svn:''' the podetached option was created post RC1<br />
<br />
==== fpHTTPClient and fpHTTPServer Units ====<br />
* '''Old behaviour:''' Old units had SSL support hardcoded built in using OpenSSL.<br />
* '''New behaviour:''' A program returns the error "No SSL Socket support compiled in" when doing a HTTPS request.<br />
* '''Reason for change:''' pluggable architecture for SSL support.<br />
* '''Remedy:''' Add one of the units ''opensslsockets'' (OpenSSL) or ''gnutlssockets'' (GNU TLS) to the uses clause of your program.<br />
<br />
== Linux/Android platforms ==<br />
<br />
=== GNU Binutils 2.19.1 or later are required by default ===<br />
* '''Old behaviour''': The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"<br />
* '''New behaviour''': The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.<br />
* '''Reason''': Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).<br />
* '''Remedy''': If you have a system with an older version of GNU Binutils, you can use the new ''-X9'' command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.<br />
<br />
=== Stack alignment on Linux/i386 ===<br />
* '''Old behaviour''': The stack alignment for Linux/i386 was 4 bytes.<br />
* '''New behaviour''': The stack alignment for Linux/i386 is 16 bytes.<br />
* '''Reason''': Compatibility with the current Linux/i386 ABI and code generated by other Linux/i386 compilers.<br />
* '''Remedy''': This change will generally only impact inline assembly code that calls subroutines. If you have such code, ensure the stack is aligned to a multiple of 16 bytes before calling any subroutine. You may also have to realign the stack to 16 bytes after routines return in case they use a calling convention whereby the callee removes any stack arguments.<br />
<br />
== i386 platforms ==<br />
<br />
=== -Ooasmcse/{$optimization asmcse} has been removed ===<br />
* '''Old behaviour''': The compiler contained an assembler common subexpression elimination pass for the i386 platform.<br />
* '''New behaviour''': This optimisation pass has been removed from the compiler.<br />
* '''Reason''': That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.<br />
* '''Remedy''': Don't use -Ooasmcse/{$optimization asmcse} anymore.<br />
<br />
== i8086 platforms ==<br />
<br />
=== the codepointer type has been changed in the small and compact memory models ===<br />
<br />
* '''Old behaviour''': The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''New behaviour''': The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''Reason''': Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.<br />
* '''Remedy''': If your program uses the small memory model and needs any kind of fixing, you're very likely to get compile time type checking errors, since the Pointer and CodePointer types are no longer compatible. To fix these, change all your pointers that point to code to CodePointer instead of Pointer. Alternatively, if your program is really small (code+data<=64k), you can switch to the tiny memory model, where the Pointer and CodePointer types are still compatible. If your program uses the compact memory model, it is unlikely to get any sort of breakage, since the Pointer and CodePointer types were already incompatible in this memory model.<br />
* '''svn''': 38691<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Default Target macOS version ===<br />
* '''Old behaviour''': The default target version for the i386 (Intel 32 bits) platform was Mac OS X 10.4 (Tiger), and for the x86-64 (Intel 64 bits) was Mac OS X 10.5 (Leopard).<br />
* '''New behaviour''': The default target version for both the i386 (Intel 32 bits) and x86-64 (Intel 64 bits) platforms is now OS X 10.8 (Mountain Lion).<br />
* '''Reason''': On macOS 10.14, installing the command line tools no longer places the crt*.o files required when targeting the older targets in the same location as before, resulting in the need for custom command line options and modifications to fpc.cfg.<br />
* '''Remedy''': If you wish to target those earlier operating system versions, use the ''-WM10.4'' resp. ''-WM10.5'' command line parameters of the compiler, and if necessary point it to an SDK that still contains support for those operating system versions with the ''-XR/path/to/SDK'' parameter (and, if necessary, to an assembler/linker that supports removed architectures with ''-FD/path/to/clang_and_ld'').<br />
* '''svn''': 43374<br />
<br />
=== Darwin/i386 and calling conventions whereby the callee removes stack parameters ===<br />
* '''Old behaviour''': The Darwin/i386 code generator treated all calling conventions as "caller removes stack parameters", even for calling conventions where this is normally not the case.<br />
* '''New behaviour''': The Darwin/i386 code generator correctly handles calling conventions whereby the callee removes the stack parameters. In particular, this changes the behaviour for the ''register'', ''stdcall'', ''safecall'', and ''pascal'' calling conventions.<br />
* '''Reason''': Respect calling conventions, compatibility with other platforms and compilers.<br />
* '''Remedy''': If you have inline assembly code that dealt with this special behaviour of Darwin/i386 under older FPC versions, you can disable it for FPC 3.2 and later. Darwin/i386 now behaves according to the same (new) rules as [[User_Changes_3.2#Stack_alignment_on_Linux.2Fi386|Linux/i386]].<br />
* '''svn''': r43650<br />
<br />
== Windows platforms ==<br />
<br />
=== GNU Binutils 2.25 or later are required by default ===<br />
* '''Old behaviour''': If the binary of a unit contains too many sections ( > $7fff) it fails to compile, due to the binary format not supporting that many sections.<br />
* '''New behaviour''': If the binary of a unit contains many sections ( > $7fff) it will be compiled using the BigObj format of COFF.<br />
* '''Reason''': Some units (e.g. ''packages\odata\src\sharepoint.pp'') got so large that they could no longer be compiled using the normal COFF format. The internal assembler and linker can handle this format as can the GNU binutils, but only starting from 2.25 on.<br />
* '''Remedy''': If you compile with the binutils instead of using the internal assembler/linker then either use an up to date version of the binutils (>= 2.25) or if you really need to use an older version, then pass -a5 which will disable the use of BigObj COFF files, though you'll then not be able to build the whole FPC distribution nor will you be able to link to such big units.<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=139147FPC New Features Trunk2020-08-12T19:25:14Z<p>PascalDragon: Documented fpcres that can now compile RC files</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Compiler ===<br />
<br />
==== fpcres can compile RC files ====<br />
<br />
* '''Overview''': The ''fpcres'' utility gained support for compiling RC files to RES files if the output format (parameter ''-of'') is set to ''rc''. The Free Pascal compiler itself can use ''fpcres'' instead of ''windres'' or ''gorc'' as well if the option ''-FF'' is supplied.<br />
* '''Notes''': Using ''fpcres'' instead of ''windres'' or ''gorc'' will become default once a release with the new ''fpcres'' is released.<br />
* '''svn''': 46398 (and others before and after that)<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''': Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
=== Units ===<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented.<br />
* '''Notes''': Delphi compatibile, currently implemented for Windows, Linux and Android. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 45160, 45206, 45233<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the sure changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for macOS/AArch64 ===<br />
* '''Overview''': The compiler can now target macOS running on AArch64<br />
* '''Notes''': The Darwin/AArch64 target corresponds to macOS/AArch64. Generating code for iOS/AArch64 requires a [[User_Changes_Trunk#The_Darwin_targets_corresponding_to_iOS_have_been_renamed_to_iOS|different command line parameter]] compared to previous versions.<br />
* '''More information''': [[macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support|Build instructions]]<br />
* '''svn''': 45762<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=139146User Changes Trunk2020-08-12T19:21:26Z<p>PascalDragon: Documented move of FileInfo unit</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Property field access lists no longer allows classes ====<br />
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.<br />
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.<br />
* '''Reason''':<br />
** Delphi compatibility<br />
** This resulted in an internal error for published properties<br />
* '''Remedy''':<br />
** Switch the fields to records or objects<br />
** Use a method with inline modifier that will result in similar performance<br />
* '''svn''': 40656<br />
* '''Example''': The following code now fails:<br />
<syntaxhighlight lang="pascal"><br />
unit Test;<br />
{$mode objfpc}<br />
<br />
interface<br />
<br />
type<br />
TTest1 = class<br />
Field: String;<br />
end;<br />
<br />
TTest2 = class<br />
private<br />
fTest1: TTest1;<br />
public<br />
property Prop: String read fTest1.Field; // Error "Record or object type expected"<br />
end;<br />
<br />
implementation<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' a<br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Range checking for enumeration constants in Delphi mode ====<br />
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.<br />
* '''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.<br />
* '''Reason''': Delphi-compatibility.<br />
* '''Remedy''': Fix the range errors.<br />
* '''svn''': 42272, 42275<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
==== FileInfo ====<br />
* '''Old behaviour:''' The ''FileInfo'' unit is part of the ''fcl-base'' package.<br />
* '''New behaviour:''' The ''FileInfo'' unit is part of the ''fcl-extra'' package.<br />
* '''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).<br />
* '''svn''': 46392<br />
<br />
== Darwin/iOS ==<br />
=== The Darwin targets corresponding to iOS have been renamed to iOS ===<br />
* '''Old behaviour:''' The Darwin/ARM and Darwin/AArch64 (ARM64) targets generated code for iOS running on those architectures.<br />
* '''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)<br />
* '''Reason for change:''' The switch of the macOS platform to AArch64 <br />
* '''svn''': 45762<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=138947FPC New Features Trunk2020-08-08T11:35:34Z<p>PascalDragon: /* = Additional control codes on Windows */</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''': Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
=== Units ===<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented.<br />
* '''Notes''': Delphi compatibile, currently implemented for Windows, Linux and Android. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 45160, 45206, 45233<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows =====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the sure changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for macOS/AArch64 ===<br />
* '''Overview''': The compiler can now target macOS running on AArch64<br />
* '''Notes''': The Darwin/AArch64 target corresponds to macOS/AArch64. Generating code for iOS/AArch64 requires a [[User_Changes_Trunk#The_Darwin_targets_corresponding_to_iOS_have_been_renamed_to_iOS|different command line parameter]] compared to previous versions.<br />
* '''More information''': [[macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support|Build instructions]]<br />
* '''svn''': 45762<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=138946FPC New Features Trunk2020-08-08T11:35:17Z<p>PascalDragon: Documented new daemon related functionality</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|previous release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''': Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided value is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
=== Units ===<br />
==== Classes ====<br />
===== Naming of Threads =====<br />
* '''Overview''': ''TThread.NameThreadForDebugging'' has been implemented.<br />
* '''Notes''': Delphi compatibile, currently implemented for Windows, Linux and Android. Read documentation as every platform has its own restrictions.<br />
* '''svn:''' 45160, 45206, 45233<br />
<br />
==== DaemonApp ====<br />
===== Additional control codes on Windows ====<br />
* '''Overview''': Windows allows a service to request additional control codes to be received. For example if the session of the sure changed. These might also carry additional parameters that need to be passed along to the ''TDaemon'' instance. For this the ''WinBindings'' class of the ''TDaemonDef'' now has an additional ''AcceptedCodes'' field (which is a set) that allows to define which additional codes should be requested. Then the daemon should handle the ''OnControlCodeEvent'' event handler which in contrast to the existing ''OnControlCode'' handler takes two additional parameters that carry the parameters that the function described for MSDNs ''[https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex LPHANDLER_FUNCTION_EX]'' takes as well.<br />
* '''Notes''': This lead to slight incompatibilities which are mentioned in [[User_Changes_Trunk#DaemonApp|User Changes Trunk]]<br />
* '''svn''': 46326, 46327<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
=== Support for macOS/AArch64 ===<br />
* '''Overview''': The compiler can now target macOS running on AArch64<br />
* '''Notes''': The Darwin/AArch64 target corresponds to macOS/AArch64. Generating code for iOS/AArch64 requires a [[User_Changes_Trunk#The_Darwin_targets_corresponding_to_iOS_have_been_renamed_to_iOS|different command line parameter]] compared to previous versions.<br />
* '''More information''': [[macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support|Build instructions]]<br />
* '''svn''': 45762<br />
<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_Trunk&diff=138945User Changes Trunk2020-08-08T11:28:35Z<p>PascalDragon: Documented daemon changes</p>
<hr />
<div>== About this page==<br />
<br />
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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_Trunk|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Language Changes ===<br />
<br />
==== Precedence of the IS operator changed ====<br />
* '''Old behaviour''': The IS operator had the same predence as the multiplication, division etc. operators.<br />
* '''New behaviour''': The IS operator has the same predence as the comparison operators.<br />
* '''Reason''': Bug, see [https://bugs.freepascal.org/view.php?id=35909].<br />
* '''Remedy''': Add parenthesis where needed.<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Property field access lists no longer allows classes ====<br />
* '''Old behaviour''': A field access list for a property is allowed to contain implicit dereferences in the form of fields of class instances.<br />
* '''New behaviour''': A field access list for a property must only contain record or (TP style) object fields.<br />
* '''Reason''':<br />
** Delphi compatibility<br />
** This resulted in an internal error for published properties<br />
* '''Remedy''':<br />
** Switch the fields to records or objects<br />
** Use a method with inline modifier that will result in similar performance<br />
* '''svn''': 40656<br />
* '''Example''': The following code now fails:<br />
<syntaxhighlight lang="pascal"><br />
unit Test;<br />
{$mode objfpc}<br />
<br />
interface<br />
<br />
type<br />
TTest1 = class<br />
Field: String;<br />
end;<br />
<br />
TTest2 = class<br />
private<br />
fTest1: TTest1;<br />
public<br />
property Prop: String read fTest1.Field; // Error "Record or object type expected"<br />
end;<br />
<br />
implementation<br />
<br />
end.<br />
</syntaxhighlight><br />
<br />
==== Disabled default support for automatic conversions of regular arrays to dynamic arrays ====<br />
* '''Old behaviour''': In FPC and ObjFPC modes, by default the compiler could automatically convert a regular array to a dynamic array.<br />
* '''New behaviour''': By default, the compiler no longer automatically converts regular arrays to dynamic arrays in any syntax mode.<br />
* '''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].<br />
* '''Remedy''': Either change the code so it no longer assigns regular arrays to dynamic arrays, or add ''{$modeswitch arraytodynarray}'' a<br />
* '''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)<br />
<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
type<br />
tdynarray = array of byte;<br />
<br />
procedure test(var arr); overload;<br />
begin<br />
pbyte(arr)[0]:=1;<br />
end;<br />
<br />
procedure test(arr: tdynarray); overload;<br />
begin<br />
test[0]:=1;<br />
end;<br />
<br />
var<br />
regulararray: array[1..1] of byte;<br />
begin<br />
regulararray[1]:=0;<br />
test(arr);<br />
writeln(arr[0]); // writes 0, because it calls test(tdynarr)<br />
end.<br />
</syntaxhighlight><br />
* '''svn''': 42118<br />
<br />
==== Range checking for enumeration constants in Delphi mode ====<br />
* '''Old behaviour''': Out-of-range enumeration constants never caused an error in Delphi mode, because very early versions of Delphi did not either.<br />
* '''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.<br />
* '''Reason''': Delphi-compatibility.<br />
* '''Remedy''': Fix the range errors.<br />
* '''svn''': 42272, 42275<br />
<br />
==== Directive clause ''[…]'' no longer useable with modeswitch ''PrefixedAttributes'' ====<br />
* '''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).<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** don't set (in non-''Delphi'' modes) or disable modeswitch ''PrefixedAttributes'' (in ''Delphi'' modes) if you don't use attributes (''{$modeswitch PrefixedAttributes-}'')<br />
** rework your directive clause:<br />
<syntaxhighlight lang="pascal"><br />
// this<br />
procedure Test; cdecl; [public,alias:'foo']<br />
begin<br />
end;<br />
<br />
// becomes this<br />
procedure Test; cdecl; public; alias:'foo';<br />
begin<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': 42402<br />
<br />
==== Type information contains reference to attribute table ====<br />
* '''Old behavior''': The first field of the data represented by ''TTypeData'' is whatever the sub branch of the case statement for the type contains.<br />
* '''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.<br />
* '''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.<br />
* '''Remedy''':<br />
** If you use the records provided by the ''TypInfo'' unit no changes ''should'' be necessary (same for the ''Rtti'' unit).<br />
** 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).<br />
* '''svn''': 42375<br />
==== Explicit values for enumeration types are limited to low(longint) ... high(longint) ====<br />
* '''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<br />
* '''New behavior''': The compiler throws an error (FPC mode) or a warning (Delphi mode) if an explicit enumeration value lies outside the longint range.<br />
* '''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".<br />
* '''Remedy''': Add Longint typecasts to values outside the valid range of a Longint.<br />
<br />
==== Comp as a type rename of Int64 instead of an alias ====<br />
* '''Old behavior''': On non-x86 as well as Win64 the Comp type is declared as an alias to Int64 (''Comp = Int64'').<br />
* '''New behavior''': On non-x86 as well as Win64 the Comp type is declared as a type rename of Int64 (''Comp = type Int64'').<br />
* '''Reason''':<br />
** This allows overloads of ''Comp'' and ''Int64'' methods/functions<br />
** This allows to better detect properties of type ''Comp''<br />
** Compatibility with Delphi for Win64 which applied the same reasoning<br />
* '''Remedy''': If you relied on ''Comp'' being able to be passed to ''Int64'' variables/parameters either include typecasts or add overloads for ''Comp''.<br />
* '''svn''': 43775<br />
<br />
=== Unit changes ===<br />
<br />
==== System - TVariantManager ====<br />
<br />
* '''Old behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''LongInt''.<br />
* '''New behaviour:''' ''TVariantManager.olevarfromint'' has a ''source'' parameter of type ''Int64''.<br />
* '''Reason for change:''' 64-bit values couldn't be correctly converted to an OleVariant.<br />
* '''Remedy:''' If you implemented your own variant manager then adjust the method signature and handle the range parameter accordingly.<br />
* '''svn:''' 41570<br />
<br />
==== 64-bit values in OleVariant ====<br />
<br />
* '''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.<br />
* '''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.<br />
* '''Reason for change:''' 64-bit values weren't correctly represented. This change is also Delphi compatible.<br />
* '''Remedy:''' Ensure that you handle 64-bit values correctly when using OleVariant.<br />
* '''svn:''' 41571<br />
<br />
==== Classes TCollection.Move ====<br />
* '''Old behaviour:''' If a TCollection.Descendant called Move() this would invoke System.Move.<br />
* '''New behaviour:''' If a TCollection.Descendant called Move() this invokes TCollection.Move.<br />
* '''Reason for change:''' New feature in TCollection: move, for consistency with other classes.<br />
* '''Remedy:''' prepend the Move() call with the system unit name: System.move().<br />
* '''svn:''' 41795<br />
<br />
==== Math Min/MaxSingle/Double ====<br />
* '''Old behaviour:''' MinSingle/MaxSingle/MinDouble/MaxDouble were set to a small/big value close to the smallest/biggest possible value.<br />
* '''New behaviour:''' The constants represent now the smallest/biggest positive normal numbers.<br />
* '''Reason for change:''' Consistency (this is also Delphi compatibility), see https://bugs.freepascal.org/view.php?id=36870.<br />
* '''Remedy:''' If the code really depends on the old values, rename them and use them as renamed.<br />
* '''svn:''' 44714<br />
<br />
==== CocoaAll ====<br />
===== CoreImage Framework Linking =====<br />
* '''Old behaviour''': Starting with FPC 3.2.0, the ''CocoaAll'' unit linked caused the ''CoreImage'' framework to be linked.<br />
* '''New behaviour''': The ''CocoaAll'' unit no longer causes the ''CoreImage'' framework to be linked.<br />
* '''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).<br />
* '''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.<br />
* '''svn''': 45767<br />
<br />
==== DB ====<br />
===== TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008) =====<br />
* '''Old behaviour:''' TMSSQLConnection used TDS protocol version 7.0 (MS SQL Server 2000).<br />
* '''New behaviour:''' TMSSQLConnection uses TDS protocol version 7.3 (MS SQL Server 2008).<br />
* '''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.<br />
* '''svn''': 42737<br />
<br />
==== DaemonApp ====<br />
===== TDaemonThread =====<br />
* '''Old behaviour:''' The virtual method ''TDaemonThread.HandleControlCode'' takes a single ''DWord'' parameter containing the control code.<br />
* '''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.<br />
* '''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.<br />
* '''svn''': 46327<br />
<br />
===== TDaemon =====<br />
* '''Old behaviour:''' If an event handler is assigned to ''OnControlCode'' then it will be called if the daemon receives a control code.<br />
* '''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.<br />
* '''Reason for change:''' This was necessary to implement the handling of additional arguments for control codes with as few backwards incompatible changes as possible.<br />
* '''svn''': 46327<br />
<br />
== Darwin/iOS ==<br />
=== The Darwin targets corresponding to iOS have been renamed to iOS ===<br />
* '''Old behaviour:''' The Darwin/ARM and Darwin/AArch64 (ARM64) targets generated code for iOS running on those architectures.<br />
* '''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)<br />
* '''Reason for change:''' The switch of the macOS platform to AArch64 <br />
* '''svn''': 45762<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_3.2.0&diff=138803User Changes 3.2.02020-08-03T19:25:17Z<p>PascalDragon: Documented FileExists change regarding directories</p>
<hr />
<div>== About this page==<br />
<br />
Listed below are intentional changes made to the FPC compiler (3.2) since the [[User_Changes_3.0.4|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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_3.2|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Usage Changes ===<br />
<br />
==== Library search directories and custom sysroots ====<br />
* '''Old behaviour''': When specifying a custom sysroot (-XR), all library search directories (both built-in and specified via options) were relative to this sysroot<br />
* '''New behaviour''': Library search directories are only relative to the sysroot if they start with "=".<br />
* '''Reason''': Allow specifying custom search directories for libraries outside a sysroot.<br />
* '''Remedy''': Add "=" at the start of library search paths if you wish them to be relative to any specified sysroot.<br />
* '''Example''':<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl=/opt/X11/lib''': will search for libraries in '''/Data/Developer/MacOSX10.4u.sdk/opt/X11/lib'''<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl=/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
* '''svn''': 43279, 43302, 43306, 43312<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Dynamic array parameters are passed like pointers ====<br />
* '''Old behaviour''': When using the default calling convention, dynamic array parameters were passed on the stack.<br />
* '''New behaviour''': When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).<br />
* '''Reason''': Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.<br />
* '''Remedy''': Adjust pure assembler routines that have dynamic array parameters.<br />
* '''svn''': 30870, 30878, 31622<br />
<br />
==== VMT Interface table uses private variable FPC_EMPTYINTF ====<br />
* '''Old behaviour''': The vIntfTable field has three possible values: <br />
**Nil if the class doesn't implement any interface (but an ancestor might)<br />
**A pointer to an interface table (with count <> 0) if the class implements any interface<br />
**A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface<br />
* '''New behaviour''': The vIntfTable field has two possible values:<br />
**Nil if neither the class nor any ancestor implements an interface<br />
**A pointer to an interface table in any other case<br />
* '''Reason''': FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems<br />
* '''Remedy''': Adjust code accordingly<br />
* '''svn''': 34087<br />
<br />
==== Modeswitch ''TypeHelpers'' in Delphi modes enables ''type helper''-syntax ====<br />
* '''Old behaviour''': The modeswitch ''TypeHelpers'' is enabled by default in Delphi modes and allows to extend primitive types with ''record helper'' types.<br />
* '''New behaviour''':<br />
**The modeswitch is no longer set by default.<br />
**Primitive types can always be extended by record helpers in Delphi modes.<br />
**The modeswitch enables the ''type helper''-syntax as known from non-Delphi modes.<br />
* '''Reason''': The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.<br />
* '''Remedy''': The only problems arise if one disabled the modeswitch on purpose which now no longer disallows the extension of primitive types.<br />
* '''svn''': 37225<br />
<br />
==== Class references in a class VMT's field table ====<br />
* '''Old behaviour''': The class array of the vFieldTable of the VMT contains an array of TClass entries<br />
* '''New behaviour''': The class array of the vFieldTable of the VMT contains an array of PClass entries<br />
* '''Reason''': As for the RTTI the indirect references are necessary for dynamic packages.<br />
* '''Remedy''': Use an additional dereferentiation to access the class type.<br />
* '''svn''': 37485<br />
<br />
=== Language Changes ===<br />
<br />
==== Visibility of generic type parameters ====<br />
* '''Old behaviour''': Type parameters of generics had ''public'' visibility.<br />
* '''New behaviour''': Type parameters of generics now have ''strict private'' visibility.<br />
* '''Reason''': With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [http://bugs.freepascal.org/view.php?id=25917 this] bug report). Also the fix is Delphi compatible.<br />
* '''Remedy''': Declare a type alias for the type parameter with the desired visibility.<br />
* '''Example''': In the following example ''T'' is declared as ''strict private'', while ''TAlias'' is declared as ''public'' and thus can be used as before the change.<br />
<syntaxhighlight lang="pascal"><br />
type<br />
generic TTest<T> = class<br />
public type<br />
TAlias = T;<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Parsing of ''specialize'' has been changed ====<br />
* '''Old behaviour''': ''specialize'' was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.<br />
* '''New behaviour''': ''specialize'' is now considered part of the specialized type, just as ''generic'' is. This means that unit names and parent types need to be used before the part containing the ''specialize''.<br />
* '''Reason''': This allows for a more logical usage of ''specialize'' in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.<br />
* '''Remedy''': Put the ''specialize'' directly in front of the type which needs to be specialized.<br />
<br />
==== Operator overload ''+'' no longer allowed for dynamic arrays ====<br />
* '''Old behaviour''': The ''+'' operator could be overloaded for dynamic array types.<br />
* '''New behaviour''': The ''+'' operator for dynamic array types can no longer be overloaded if the modeswitch ''ArrayOperators'' is active (default in Delphi modes).<br />
* '''Reason''': When the modeswitch ''ArrayOperators'' is active a ''+'' operator is now provided by the compiler itself which concatenates two arrays together.<br />
* '''Remedy''':<br />
** Disable the modeswitch (for Delphi modes this can be done with ''{$modeswitch ArrayOperators-}'').<br />
** If your operator merely concatenates two arrays then remove the overload.<br />
** If your operator does something different or more then use a different operator.<br />
* '''Note''': A warning is provided by the compiler if an overload is in scope, but not used due to the internal operator.<br />
<br />
==== Generic type parameters need to match ====<br />
* '''Old behaviour''': When defining the method of a generic class or record it was possible to use different names for the type parameters than those that were used in the declaration.<br />
* '''New behaviour''': The order and name of generic type parameters of the class or record type in the method definition has to match the order and name of generic types parameters of the class or record declaration.<br />
* '''Reason''': To avoid the user making mistakes e.g. when the order of parameters is swapped. Also this is compatible to at least newer Delphi versions.<br />
* '''Remedy''': Use the correct generic type parameters for the definition.<br />
* '''svn''': 39701<br />
<br />
==== Visibility of methods implementing interface methods ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces<br />
* '''New behaviour''': Only methods visible in the class that is declared as implementing the method are considered.<br />
* '''Reason''': The symbol visibility rules should be respected in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Make (strict) private methods that should implement interface methods in descendant classes protected or public.<br />
* '''svn''': 40645<br />
<br />
==== Methods implementing interface methods and overloads ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces.<br />
* '''New behaviour''': In case of overloads, searching stops when a method is found that has the right name but not the ''overload'' directive. Note that this directive is automatically inherited when overriding a method.<br />
* '''Reason''': The same happens when calling a method, and the symbol resolution rules should be the same in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Add an ''overload'' directive to methods of which all overloads should be visible in the entire class hierarchy.<br />
* '''Example''':<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw27349.pp?r1=40683&r2=40682&pathrev=40683 Bug found by this change] (previously, on non-Windows platforms the '''_Addref''' method of ''TInterfacedObject'' was selected for implementing by the classes implementing ''tmyintf'').<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbf/tb0267.pp?view=markup Example that no longer compiles].<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbs/tb0654.pp?view=markup Fixed example].<br />
* '''svn''': 40683<br />
<br />
==== Objective-C "Related Result Type" ====<br />
* '''Old behaviour''': The type checking system always evaluated calls to Objective-C methods as them returning the declared result type.<br />
* '''New behaviour''': The type checking system now takes into account the [http://releases.llvm.org/8.0.0/tools/clang/docs/LanguageExtensions.html#objective-c-features "related result type"] rule from Objective-C. This means that certain methods are now assumed to always return an instance whose type is compatible with the object to which the message was sent (i.e., it's the same, or inherits from it). This is done for the following methods, provided their declared result type is also compatible with the class type in which the method is declared:<br />
** instance methods whose first lower case word in the message name is ''init'' or ''new''<br />
** class methods whose first lower case word in the message name is ''autorelease'', ''init'', ''retain'', or ''self''<br />
* '''Reason''': Compatibility with translations of more recent versions of Cocoa headers<br />
* '''Remedy''': Normally this should not break existing, correct code. If it does, you can probably fix it by removing superfluous typecasts.<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
{$modeswitch objectivec1}<br />
<br />
type<br />
FPCMyType = objcclass<br />
function init: id; message 'init';<br />
class function alloc: FPCMyType; message 'initWithValue';<br />
// since ObjCBool is not related to FPCMyType, the "related result type" rule will not apply here<br />
// even though the message starts with "retain" and it's a class method<br />
class function retainCounting: ObjCBool; message 'retainCounting';<br />
end;<br />
<br />
...<br />
<br />
var<br />
a: NSArray;<br />
begin<br />
// will give an error even though FPCMyType returns 'id', because 'id' is related to<br />
// FPCMyType and hence the compiler will now interpret the 'init' message as returning<br />
// an "FPCMyType" when called. Do note that the actual return type of "init" remains<br />
// "id" in all other contexts, e.g. when deciding override compatibility. The declaration<br />
// of that method is not modified, and the only changed behviour is that when calling it<br />
// the result type is statically assumed to be of FPCMyType.<br />
a:=FPCMyType.alloc.init;<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': r42816<br />
<br />
=== RTTI changes ===<br />
<br />
==== RTTI for Interfaces (published property count) ====<br />
* '''Old behavior''': The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count. <br />
* '''New behavior''': Before the property RTTI data is now a Word count field that specifies the amount of properties<br />
* '''Reason''': Both user request and usability.<br />
* '''Remedy''': Adjust pointer offsets accessing the property data accordingly.<br />
<br />
==== RTTI for COM Interfaces (IID String) ====<br />
* '''Old behavior''': COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.<br />
* '''New behavior''': The undocumented field has been removed.<br />
* '''Reason''': The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.<br />
* '''Remedy''': Use the GUID field and convert that to a String.<br />
<br />
==== RTTI Binary format change ====<br />
* '''Old behavior''': References to other types are designated by PTypeInfo.<br />
* '''New behavior''': References to other types are designated by PPTypeInfo.<br />
* '''Reason''': While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.<br />
* '''Remedy''': If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.<br />
* '''Note''': <br />
**The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.<br />
**This does not apply to TObject.ClassInfo which still returns a PTypeInfo<br />
<br />
==== RTTI for Corba Interfaces (IID String) ====<br />
* '''Old behavior''': IIDStr is a field of TTypeData.<br />
* '''New behavior''': IIDStr is a property of TTypeData.<br />
* '''Reason''': The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.<br />
* '''Remedy''': If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.<br />
* '''svn''': 35026<br />
<br />
==== Reference to Record Init Information ====<br />
* '''Old behavior''': Field RecSize follows directly after start of TTypeData record.<br />
* '''New behavior''': Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).<br />
* '''Reason''': With the record init information one can more quickly decide whehther a record needs to be classed as ''managed'' or not which is among others useful for the IsManaged() function of the Rtti unit.<br />
* '''Remedy''': If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.<br />
* '''Note''': The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.<br />
* '''svn''': 35125, 35134<br />
<br />
==== TOrdType extended ====<br />
* '''Old behavior''': TOrdType contains entries for 8-, 16- and 32-bit widths.<br />
* '''New behavior''': TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.<br />
* '''Reason''': Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.<br />
* '''Remedy''': Adjust arrays that have TOrdType as index.<br />
* '''svn''': 35135<br />
<br />
==== New OrdType field for tkInt64 and tkQWord ====<br />
* '''Old behavior''': MinInt64Value and MinQWordValue follow directly after start of TTypeData record.<br />
* '''New behavior''': MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.<br />
* '''Reason''': To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.<br />
* '''Remedy''': If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.<br />
* '''svn''': 35135<br />
<br />
==== First field of TProcedureParam changed ====<br />
* '''Old behavior''': First field of TProcedureParam is called Flags and has type Byte.<br />
* '''New behavior''': First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.<br />
* '''Reason''': Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.<br />
* '''Remedy''': Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.<br />
* '''svn''': 35174<br />
<br />
==== TParamFlag extended for constref ====<br />
* '''Old behavior''': TParamFlag has no entry for constref parameters.<br />
* '''New behavior''': TParamFlag has entry pfConstRef for constref parameters.<br />
* '''Reason''': To correctly detect constref parameters they need to be marked accordingly.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).<br />
* '''svn''': 35175<br />
<br />
==== Ranges of Boolean types adjusted ====<br />
* '''Old behavior''': ByteBool, WordBool and LongBool have a range of 0..-1.<br />
* '''New behavior''': ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).<br />
* '''Reason''': The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.<br />
* '''Remedy''': Adjust code that might have relied on the range being ''invalid''.<br />
* '''svn''': 35184<br />
<br />
==== OrdType of Boolean64 and QWordBool adjusted ====<br />
* '''Old behavior''': Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.<br />
* '''New behavior''': Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.<br />
* '''Reason''': Both types have a size of 64-bit thus using a smaller size is incorrect.<br />
* '''Remedy''': Use the correct fields to retrieve the range boundaries of the types.<br />
* '''svn''': 35185<br />
<br />
==== All Boolean types have TypeKind tkBool ====<br />
* '''Old behavior''': Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.<br />
* '''New behavior''': Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.<br />
* '''Reason''': Consistency and possibility to differentiate ordinary subranges from the real Boolean types.<br />
* '''Remedy''': Check for TypeKind tkBool instead of some "magic" to detect Boolean types.<br />
* '''Note''': Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.<br />
* '''svn''': 35186, 35187<br />
<br />
==== TParamFlag extended for hidden parameters ====<br />
* '''Old behavior''': TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1<br />
* '''New behavior''': TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2<br />
* '''Reason''': As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).<br />
* '''svn''': 35267, 35286, 35291<br />
<br />
==== Parameters of method pointer variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of method pointer variables only listed visible parameters.<br />
* '''New behavior''': The parameters of method pointer variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
==== Parameters of procedure variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of procedure variables only listed visible parameters.<br />
* '''New behavior''': The parameters of procedure variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
=== Unit changes ===<br />
<br />
==== SysUtils ====<br />
<br />
===== faSymlink =====<br />
* '''Old behaviour:''' faSymlink had the numerical value $40. This was wrong on windows, and not compatible with Delphi.<br />
* '''New behaviour:''' faSymlink has the numerical value $400. Correct on windows.<br />
* '''Reason for change:''' Wrong functionality and Delphi compatibility.<br />
* '''Remedy:''' If you are using the old numerical constant $40, simply use faSymlink instead.<br />
* '''svn:''' r33340<br />
<br />
===== FileExists on Unix-based systems =====<br />
* '''Old behaviour:''' ''FileExists'' returns ''True'' for existing directories.<br />
* '''New behaviour:''' ''FileExists'' does not return ''True'' for existing directories.<br />
* '''Reason for change:''' Directories are not files, thus it was illogical for ''FileExists'' to return ''True'' for existing directories. Also this brings it in line with Windows and Delphi.<br />
* '''Remedy:''' Use ''DirectoryExists'' to check for the existance of a directory<br />
* '''svn:''' r43111<br />
<br />
==== Classes.TList auto-growth ====<br />
* '''Old behaviour:''' Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity<br />
* '''New behaviour:''' Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.<br />
* '''Reason for change:''' Avoid out-of-memory when very large lists are expanded<br />
* '''svn:''' 34462<br />
<br />
==== Math Min/Max ====<br />
* '''Old behaviour:''' Mixing of QWord and Int64 was possible as there was no QWord overload. However the result might have been wrong.<br />
* '''New behaviour:''' Overload for QWord exists now but mixed calls with Int64/QWord cause a compiler error.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Apply an explicit typecast to one of the parameters so both are of the same type.<br />
* '''svn:''' 39995<br />
<br />
==== StrUtils AnsiStartsText/AnsiEndsText ====<br />
* '''Old behaviour:''' AnsiStartsText or AnsiEndsText would return false for empty substring. This is not in line with Delphi, which returns true.<br />
* '''New behaviour:''' AnsiStartsText or AnsiEndsText now return True for empty substring.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Check explicitly for empty string if you counted on the old behaviour.<br />
* '''svn:''' 38768<br />
<br />
==== Types IStream interface and Classes TStreamAdapter ====<br />
* '''Old behaviour:''' IStream Interface (classes unit and jwa units) used Int64 for various out parameters.<br />
* '''New behaviour:''' IStream Interface (classes unit and jwa units) use QWord for various out parameters.<br />
* '''Reason for change:''' The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.<br />
* '''Remedy:''' If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.<br />
* '''svn:''' 32820 and 35542<br />
<br />
==== Baseunix (Linux only) ====<br />
* '''Old behaviour:''' stat was an union, with one side the proper posix fieldnames, and the other deprecated, simplified 1.0.x fieldnames. The 1.0.x were already marked as deprecated for 2 major cycles.<br />
* '''New behaviour:''' Deprecated 1.0.x fieldnames removed.<br />
* '''Reason for change:''' Left over 1.0.x transition feature. Incompatible with other *nix ports. <br />
* '''Remedy:''' Update fieldnames <br />
* '''svn:''' 39644 and 39655<br />
<br />
==== Classes TStrings.LoadFromStream/File encoding handling ====<br />
* '''Old behaviour:''' The LoadFromStream call totally ignored the encoding of a file, loading it from a stream without regard for encoding, unless an encoding was specified. <br />
* '''New behaviour:''' There is an overloaded call with a Boolean parameter 'IgnoreEncoding' which determines whether the encoding should be taken into account or not. By default, this parameter is False, meaning that LoadFromStream with just a stream as argument now calls the encoding-aware version of LoadFromStream, passing it an encoding of Nil, which mean the default encoding will be used.<br />
* '''Reason for change:''' Delphi compatibility, and the corresponding changes in TStringStream constructors.<br />
* '''Remedy:''' The old behaviour can be restored by setting the IgnoreEncoding parameter to 'True'.<br />
* '''svn:''' 37962 and 37965<br />
<br />
===== TStringStream now observes system encoding =====<br />
* '''Old behaviour''': TStringStream copied bytes as-is from the string specified in the constructor. <br />
* '''New behaviour''': Now bytes are fetched from the string using the encoding of the string.<br />
* '''Reason:''' Delphi-compatibility<br />
* '''Remedy:''' Pass a string with the correct encoding to TStringStream<br />
* '''svn''': 36758<br />
<br />
==== DB ====<br />
===== TParam.LoadFromFile sets share mode to fmShareDenyWrite =====<br />
* '''Old behaviour''': TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file<br />
* '''New behaviour''': TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file<br />
* '''Remedy''': If your application requires exclusive access to file specify fmShareExclusive<br />
<br />
===== CodePage aware TStringField and TMemoField =====<br />
* '''Old behaviour''': These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.<br />
* '''New behaviour''': When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.<br />
<br />
===== ODBC headers on Unix platforms defaults to 3.52 version =====<br />
* '''Old behaviour''': default was ODBCVER $0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.<br />
* '''New behaviour''': default is ODBCVER $0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).<br />
<br />
===== TBlobData opaque type reworked to TBytes =====<br />
* '''Old behaviour''': TBlobData was declared as Ansistring<br />
* '''New behaviour''': TBlobData is declared as TBytes <br />
* '''Reason for change''': Delphi compatibility. Also helps to avoid possible code page recodings.<br />
* '''Remedy''': If your application used TBlobData as a string, you can use AsString for parameters, or convert to TBytes.<br />
<br />
==== FGL ====<br />
===== Declaration of type TTypeList changed =====<br />
* '''Old behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''array[0..GMaxListSize] of T''.<br />
* '''New behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''PT''.<br />
* '''Reason''': The way ''GMaxListSize'' was declared this could lead to too large static array types so that compilation aborted with a ''Data segment too large'' error. This also might have lead to incorrect range errors if range checking was turned on. As FPC supports indexed access to pointer types potential type problems when using the ''List'' property should be minimal.<br />
* '''Remedy''': If your application relies on ''PTypeList'' to be a static array type (instead of merely being indexable like an array) then you'll need to adjust your code.<br />
* '''svn''': 39464<br />
<br />
==== objcbase ====<br />
* '''Old behaviour''': The Objective-C BOOL type was represented by objcbase.BOOL, which was the same as a Pascal boolean on all platforms.<br />
* '''New behaviour''': The Objective-C BOOL type is now represented by objcbase.ObjCBOOL, which maps to a boolean type that always corresponds to the one used in Objective-C (it differs on some platforms)<br />
* '''Reason''': The renaming was to prevent name clashes, and the type definition change was to fix interfacing issues between Objective-Pascal and Objective-C<br />
* '''Remedy''': change all uses of Boolean and BOOL in Objective-Pascal method definitions to ObjCBool.<br />
* '''svn''': 42483<br />
<br />
==== SimpleIPC ====<br />
* '''Old behaviour''': ReadMessage is a procedure.<br />
* '''New behaviour''': ReadMessage is a function, returning a boolean, telling you whether a message was actually read.<br />
* '''Reason''': Provide more information to the user. <br />
* '''Remedy''': Handle the result if necessary. (if you used OnMessage, no change is necessary)<br />
* '''svn''': 36916<br />
<br />
<br />
==== Process Unit ====<br />
<br />
===== Runcommand =====<br />
* '''Old behaviour:''' Runcommand had a few short sleeps to reduce CPU usage when the called process ran long.<br />
* '''New behaviour:''' Runcommand defaults to no sleep unless poRunIdle is passed to the default parameter with process options.<br />
* '''Reason for change:''' Applications that ran binaries to quickly obtain information were stalled by the pauses for no good reason. Servicing both short and long running binaries adequately without additional info seemed impossible due to slightly differing OS behaviours in pipe reading.<br />
* '''Remedy:''' For short living processes that start up quickly: do nothing. For long running processes, pass poRunIdle as process option.<br />
* '''svn:''' this changes was merged post RC1<br />
<br />
===== pnoconsole on Windows =====<br />
* '''Old behaviour:''' On Windows, ponoconsole mapped to winapi DETACH_PROCESS which still created standard input/output/error handles.<br />
* '''New behaviour:''' ponewconsole maps to CREATE_NO_WINDOW, which doesn't create input/output/error handles. A new option podetached allows for DETACH_PROCESS<br />
* '''Reason for change:''' ponoconsole still created a window in cases. (mantis [https://bugs.freepascal.org/view.php?id=32055 bug 32055]). <br />
* '''Remedy:''' If you try to hide the console but still need stdin/stdout handles, then ponoconsole no longer works. You could try podetached. See also [https://forum.lazarus.freepascal.org/index.php/topic,49631.msg360286.html#msg360286 podetached forum thread]<br />
* '''svn:''' the podetached option was created post RC1<br />
<br />
== Linux/Android platforms ==<br />
<br />
=== GNU Binutils 2.19.1 or later are required by default ===<br />
* '''Old behaviour''': The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"<br />
* '''New behaviour''': The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.<br />
* '''Reason''': Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).<br />
* '''Remedy''': If you have a system with an older version of GNU Binutils, you can use the new ''-X9'' command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.<br />
<br />
=== Stack alignment on Linux/i386 ===<br />
* '''Old behaviour''': The stack alignment for Linux/i386 was 4 bytes.<br />
* '''New behaviour''': The stack alignment for Linux/i386 is 16 bytes.<br />
* '''Reason''': Compatibility with the current Linux/i386 ABI and code generated by other Linux/i386 compilers.<br />
* '''Remedy''': This change will generally only impact inline assembly code that calls subroutines. If you have such code, ensure the stack is aligned to a multiple of 16 bytes before calling any subroutine. You may also have to realign the stack to 16 bytes after routines return in case they use a calling convention whereby the callee removes any stack arguments.<br />
<br />
== i386 platforms ==<br />
<br />
=== -Ooasmcse/{$optimization asmcse} has been removed ===<br />
* '''Old behaviour''': The compiler contained an assembler common subexpression elimination pass for the i386 platform.<br />
* '''New behaviour''': This optimisation pass has been removed from the compiler.<br />
* '''Reason''': That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.<br />
* '''Remedy''': Don't use -Ooasmcse/{$optimization asmcse} anymore.<br />
<br />
== i8086 platforms ==<br />
<br />
=== the codepointer type has been changed in the small and compact memory models ===<br />
<br />
* '''Old behaviour''': The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''New behaviour''': The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''Reason''': Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.<br />
* '''Remedy''': If your program uses the small memory model and needs any kind of fixing, you're very likely to get compile time type checking errors, since the Pointer and CodePointer types are no longer compatible. To fix these, change all your pointers that point to code to CodePointer instead of Pointer. Alternatively, if your program is really small (code+data<=64k), you can switch to the tiny memory model, where the Pointer and CodePointer types are still compatible. If your program uses the compact memory model, it is unlikely to get any sort of breakage, since the Pointer and CodePointer types were already incompatible in this memory model.<br />
* '''svn''': 38691<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Default Target macOS version ===<br />
* '''Old behaviour''': The default target version for the i386 (Intel 32 bits) platform was Mac OS X 10.4 (Tiger), and for the x86-64 (Intel 64 bits) was Mac OS X 10.5 (Leopard).<br />
* '''New behaviour''': The default target version for both the i386 (Intel 32 bits) and x86-64 (Intel 64 bits) platforms is now OS X 10.8 (Mountain Lion).<br />
* '''Reason''': On macOS 10.14, installing the command line tools no longer places the crt*.o files required when targeting the older targets in the same location as before, resulting in the need for custom command line options and modifications to fpc.cfg.<br />
* '''Remedy''': If you wish to target those earlier operating system versions, use the ''-WM10.4'' resp. ''-WM10.5'' command line parameters of the compiler, and if necessary point it to an SDK that still contains support for those operating system versions with the ''-XR/path/to/SDK'' parameter (and, if necessary, to an assembler/linker that supports removed architectures with ''-FD/path/to/clang_and_ld'').<br />
* '''svn''': 43374<br />
<br />
=== Darwin/i386 and calling conventions whereby the callee removes stack parameters ===<br />
* '''Old behaviour''': The Darwin/i386 code generator treated all calling conventions as "caller removes stack parameters", even for calling conventions where this is normally not the case.<br />
* '''New behaviour''': The Darwin/i386 code generator correctly handles calling conventions whereby the callee removes the stack parameters. In particular, this changes the behaviour for the ''register'', ''stdcall'', ''safecall'', and ''pascal'' calling conventions.<br />
* '''Reason''': Respect calling conventions, compatibility with other platforms and compilers.<br />
* '''Remedy''': If you have inline assembly code that dealt with this special behaviour of Darwin/i386 under older FPC versions, you can disable it for FPC 3.2 and later. Darwin/i386 now behaves according to the same (new) rules as [[User_Changes_3.2#Stack_alignment_on_Linux.2Fi386|Linux/i386]].<br />
* '''svn''': r43650<br />
<br />
== Windows platforms ==<br />
<br />
=== GNU Binutils 2.25 or later are required by default ===<br />
* '''Old behaviour''': If the binary of a unit contains too many sections ( > $7fff) it fails to compile, due to the binary format not supporting that many sections.<br />
* '''New behaviour''': If the binary of a unit contains many sections ( > $7fff) it will be compiled using the BigObj format of COFF.<br />
* '''Reason''': Some units (e.g. ''packages\odata\src\sharepoint.pp'') got so large that they could no longer be compiled using the normal COFF format. The internal assembler and linker can handle this format as can the GNU binutils, but only starting from 2.25 on.<br />
* '''Remedy''': If you compile with the binutils instead of using the internal assembler/linker then either use an up to date version of the binutils (>= 2.25) or if you really need to use an older version, then pass -a5 which will disable the use of BigObj COFF files, though you'll then not be able to build the whole FPC distribution nor will you be able to link to such big units.<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=User_Changes_3.2.0&diff=138802User Changes 3.2.02020-08-03T19:21:53Z<p>PascalDragon: TList is in Classes, not SysUtils</p>
<hr />
<div>== About this page==<br />
<br />
Listed below are intentional changes made to the FPC compiler (3.2) since the [[User_Changes_3.0.4|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. <br />
<br />
The list of new features that do not break existing code can be found [[FPC_New_Features_3.2|here]].<br />
<br />
Please add revision numbers to the entries from now on. This facilitates moving merged items to the user changes of a release.<br />
<br />
== All systems ==<br />
<br />
=== Usage Changes ===<br />
<br />
==== Library search directories and custom sysroots ====<br />
* '''Old behaviour''': When specifying a custom sysroot (-XR), all library search directories (both built-in and specified via options) were relative to this sysroot<br />
* '''New behaviour''': Library search directories are only relative to the sysroot if they start with "=".<br />
* '''Reason''': Allow specifying custom search directories for libraries outside a sysroot.<br />
* '''Remedy''': Add "=" at the start of library search paths if you wish them to be relative to any specified sysroot.<br />
* '''Example''':<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl=/opt/X11/lib''': will search for libraries in '''/Data/Developer/MacOSX10.4u.sdk/opt/X11/lib'''<br />
** '''-XR/Data/Developer/MacOSX10.4u.sdk/ -Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl=/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
** '''-Fl/opt/X11/lib''': will search for libraries in '''/opt/X11/lib'''<br />
* '''svn''': 43279, 43302, 43306, 43312<br />
<br />
=== Implementation Changes ===<br />
<br />
==== Dynamic array parameters are passed like pointers ====<br />
* '''Old behaviour''': When using the default calling convention, dynamic array parameters were passed on the stack.<br />
* '''New behaviour''': When using the default calling convention, dynamic array parameters are now passed like a pointer (which may be in a register).<br />
* '''Reason''': Delphi compatibility, ensuring that SetPointerProp can be used with dynamic arrays.<br />
* '''Remedy''': Adjust pure assembler routines that have dynamic array parameters.<br />
* '''svn''': 30870, 30878, 31622<br />
<br />
==== VMT Interface table uses private variable FPC_EMPTYINTF ====<br />
* '''Old behaviour''': The vIntfTable field has three possible values: <br />
**Nil if the class doesn't implement any interface (but an ancestor might)<br />
**A pointer to an interface table (with count <> 0) if the class implements any interface<br />
**A pointer to FPC_EMPTYINTF if neither the class itself nor any ancestor implements an interface<br />
* '''New behaviour''': The vIntfTable field has two possible values:<br />
**Nil if neither the class nor any ancestor implements an interface<br />
**A pointer to an interface table in any other case<br />
* '''Reason''': FPC_EMPTYINTF had to be removed due to dynamic packages support on PE-based systems<br />
* '''Remedy''': Adjust code accordingly<br />
* '''svn''': 34087<br />
<br />
==== Modeswitch ''TypeHelpers'' in Delphi modes enables ''type helper''-syntax ====<br />
* '''Old behaviour''': The modeswitch ''TypeHelpers'' is enabled by default in Delphi modes and allows to extend primitive types with ''record helper'' types.<br />
* '''New behaviour''':<br />
**The modeswitch is no longer set by default.<br />
**Primitive types can always be extended by record helpers in Delphi modes.<br />
**The modeswitch enables the ''type helper''-syntax as known from non-Delphi modes.<br />
* '''Reason''': The previous implementation of the modeswitch was illogical additionally there were user wishes to allow inheritance for record helpers in Delphi modes.<br />
* '''Remedy''': The only problems arise if one disabled the modeswitch on purpose which now no longer disallows the extension of primitive types.<br />
* '''svn''': 37225<br />
<br />
==== Class references in a class VMT's field table ====<br />
* '''Old behaviour''': The class array of the vFieldTable of the VMT contains an array of TClass entries<br />
* '''New behaviour''': The class array of the vFieldTable of the VMT contains an array of PClass entries<br />
* '''Reason''': As for the RTTI the indirect references are necessary for dynamic packages.<br />
* '''Remedy''': Use an additional dereferentiation to access the class type.<br />
* '''svn''': 37485<br />
<br />
=== Language Changes ===<br />
<br />
==== Visibility of generic type parameters ====<br />
* '''Old behaviour''': Type parameters of generics had ''public'' visibility.<br />
* '''New behaviour''': Type parameters of generics now have ''strict private'' visibility.<br />
* '''Reason''': With the previous visibility it was possible to create code that leads to infinite loops during compilation or other hard to debug errors. In addition there is no real possibility to work around this issue (for an example see [http://bugs.freepascal.org/view.php?id=25917 this] bug report). Also the fix is Delphi compatible.<br />
* '''Remedy''': Declare a type alias for the type parameter with the desired visibility.<br />
* '''Example''': In the following example ''T'' is declared as ''strict private'', while ''TAlias'' is declared as ''public'' and thus can be used as before the change.<br />
<syntaxhighlight lang="pascal"><br />
type<br />
generic TTest<T> = class<br />
public type<br />
TAlias = T;<br />
end;<br />
</syntaxhighlight><br />
<br />
==== Parsing of ''specialize'' has been changed ====<br />
* '''Old behaviour''': ''specialize'' was used to initialize a specialization and was followed by a type name that might contain a unit name and parent types.<br />
* '''New behaviour''': ''specialize'' is now considered part of the specialized type, just as ''generic'' is. This means that unit names and parent types need to be used before the part containing the ''specialize''.<br />
* '''Reason''': This allows for a more logical usage of ''specialize'' in context with nested types (especially if multiple specializations are involved) and more importantly generic functions and methods.<br />
* '''Remedy''': Put the ''specialize'' directly in front of the type which needs to be specialized.<br />
<br />
==== Operator overload ''+'' no longer allowed for dynamic arrays ====<br />
* '''Old behaviour''': The ''+'' operator could be overloaded for dynamic array types.<br />
* '''New behaviour''': The ''+'' operator for dynamic array types can no longer be overloaded if the modeswitch ''ArrayOperators'' is active (default in Delphi modes).<br />
* '''Reason''': When the modeswitch ''ArrayOperators'' is active a ''+'' operator is now provided by the compiler itself which concatenates two arrays together.<br />
* '''Remedy''':<br />
** Disable the modeswitch (for Delphi modes this can be done with ''{$modeswitch ArrayOperators-}'').<br />
** If your operator merely concatenates two arrays then remove the overload.<br />
** If your operator does something different or more then use a different operator.<br />
* '''Note''': A warning is provided by the compiler if an overload is in scope, but not used due to the internal operator.<br />
<br />
==== Generic type parameters need to match ====<br />
* '''Old behaviour''': When defining the method of a generic class or record it was possible to use different names for the type parameters than those that were used in the declaration.<br />
* '''New behaviour''': The order and name of generic type parameters of the class or record type in the method definition has to match the order and name of generic types parameters of the class or record declaration.<br />
* '''Reason''': To avoid the user making mistakes e.g. when the order of parameters is swapped. Also this is compatible to at least newer Delphi versions.<br />
* '''Remedy''': Use the correct generic type parameters for the definition.<br />
* '''svn''': 39701<br />
<br />
==== Visibility of methods implementing interface methods ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces<br />
* '''New behaviour''': Only methods visible in the class that is declared as implementing the method are considered.<br />
* '''Reason''': The symbol visibility rules should be respected in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Make (strict) private methods that should implement interface methods in descendant classes protected or public.<br />
* '''svn''': 40645<br />
<br />
==== Methods implementing interface methods and overloads ====<br />
* '''Old behaviour''': All methods in a class hierarchy were considered when looking for methods to implement interfaces.<br />
* '''New behaviour''': In case of overloads, searching stops when a method is found that has the right name but not the ''overload'' directive. Note that this directive is automatically inherited when overriding a method.<br />
* '''Reason''': The same happens when calling a method, and the symbol resolution rules should be the same in all cases. This fix is Delphi-compatible.<br />
* '''Remedy''': Add an ''overload'' directive to methods of which all overloads should be visible in the entire class hierarchy.<br />
* '''Example''':<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw27349.pp?r1=40683&r2=40682&pathrev=40683 Bug found by this change] (previously, on non-Windows platforms the '''_Addref''' method of ''TInterfacedObject'' was selected for implementing by the classes implementing ''tmyintf'').<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbf/tb0267.pp?view=markup Example that no longer compiles].<br />
** [https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tbs/tb0654.pp?view=markup Fixed example].<br />
* '''svn''': 40683<br />
<br />
==== Objective-C "Related Result Type" ====<br />
* '''Old behaviour''': The type checking system always evaluated calls to Objective-C methods as them returning the declared result type.<br />
* '''New behaviour''': The type checking system now takes into account the [http://releases.llvm.org/8.0.0/tools/clang/docs/LanguageExtensions.html#objective-c-features "related result type"] rule from Objective-C. This means that certain methods are now assumed to always return an instance whose type is compatible with the object to which the message was sent (i.e., it's the same, or inherits from it). This is done for the following methods, provided their declared result type is also compatible with the class type in which the method is declared:<br />
** instance methods whose first lower case word in the message name is ''init'' or ''new''<br />
** class methods whose first lower case word in the message name is ''autorelease'', ''init'', ''retain'', or ''self''<br />
* '''Reason''': Compatibility with translations of more recent versions of Cocoa headers<br />
* '''Remedy''': Normally this should not break existing, correct code. If it does, you can probably fix it by removing superfluous typecasts.<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
{$mode objfpc}<br />
{$modeswitch objectivec1}<br />
<br />
type<br />
FPCMyType = objcclass<br />
function init: id; message 'init';<br />
class function alloc: FPCMyType; message 'initWithValue';<br />
// since ObjCBool is not related to FPCMyType, the "related result type" rule will not apply here<br />
// even though the message starts with "retain" and it's a class method<br />
class function retainCounting: ObjCBool; message 'retainCounting';<br />
end;<br />
<br />
...<br />
<br />
var<br />
a: NSArray;<br />
begin<br />
// will give an error even though FPCMyType returns 'id', because 'id' is related to<br />
// FPCMyType and hence the compiler will now interpret the 'init' message as returning<br />
// an "FPCMyType" when called. Do note that the actual return type of "init" remains<br />
// "id" in all other contexts, e.g. when deciding override compatibility. The declaration<br />
// of that method is not modified, and the only changed behviour is that when calling it<br />
// the result type is statically assumed to be of FPCMyType.<br />
a:=FPCMyType.alloc.init;<br />
end;<br />
</syntaxhighlight><br />
* '''svn''': r42816<br />
<br />
=== RTTI changes ===<br />
<br />
==== RTTI for Interfaces (published property count) ====<br />
* '''Old behavior''': The property RTTI data of an interface (both COM and Corba) immediately followed the TTypeData record without any count. <br />
* '''New behavior''': Before the property RTTI data is now a Word count field that specifies the amount of properties<br />
* '''Reason''': Both user request and usability.<br />
* '''Remedy''': Adjust pointer offsets accessing the property data accordingly.<br />
<br />
==== RTTI for COM Interfaces (IID String) ====<br />
* '''Old behavior''': COM interfaces contain an undocumented IIDStr between the unit name IntfUnit and the property data.<br />
* '''New behavior''': The undocumented field has been removed.<br />
* '''Reason''': The IID of COM interfaces can always be represented as GUID, thus the undocumented IIDStr field is redundant.<br />
* '''Remedy''': Use the GUID field and convert that to a String.<br />
<br />
==== RTTI Binary format change ====<br />
* '''Old behavior''': References to other types are designated by PTypeInfo.<br />
* '''New behavior''': References to other types are designated by PPTypeInfo.<br />
* '''Reason''': While the change in the binary format is Delphi-compatible the reason for this is the introduction of the support for dynamic packages and the rules of the PE file format (Windows) that need to be played by.<br />
* '''Remedy''': If you don't access the binary data directly then there should be no change necessary. Otherwise you need to add in a further derefentiation.<br />
* '''Note''': <br />
**The PPTypeInfo value itself will be Nil if there's no reference, not the PTypeInfo reference stored in it.<br />
**This does not apply to TObject.ClassInfo which still returns a PTypeInfo<br />
<br />
==== RTTI for Corba Interfaces (IID String) ====<br />
* '''Old behavior''': IIDStr is a field of TTypeData.<br />
* '''New behavior''': IIDStr is a property of TTypeData.<br />
* '''Reason''': The compiler assumes the RawIntfUnit field immediately preceding IIDStr is a ShortString of length 255 despite the corresponding binary data only having the length of the string it contains, thus accessing incorrect data.<br />
* '''Remedy''': If you merely accessed the data nothing changes, but the data following IIDStr needs to be accessed differently as RawIntfUnit is the last visible field.<br />
* '''svn''': 35026<br />
<br />
==== Reference to Record Init Information ====<br />
* '''Old behavior''': Field RecSize follows directly after start of TTypeData record.<br />
* '''New behavior''': Field RecSize is preceeded by pointer field RecInitInfo which points to a TTypeInfo for the record init information (the TTypeInfo for that is followed by TRecInitData).<br />
* '''Reason''': With the record init information one can more quickly decide whehther a record needs to be classed as ''managed'' or not which is among others useful for the IsManaged() function of the Rtti unit.<br />
* '''Remedy''': If you relied on the relative position of RecSize in TTypeData you'll need to adjust your code.<br />
* '''Note''': The TRecInitData shares its first three fields with a record's TTypeData with the difference that the pointer to the init information is Nil.<br />
* '''svn''': 35125, 35134<br />
<br />
==== TOrdType extended ====<br />
* '''Old behavior''': TOrdType contains entries for 8-, 16- and 32-bit widths.<br />
* '''New behavior''': TOrdType contains entries for 8-, 16-, 32- and 64-bit widths.<br />
* '''Reason''': Without extending TOrdType it wouldn't be possible to correctly represent Boolean type of 64-bit width as they couldn't be differentiated from ordinary Integers with a minimum of 0 and maximum of 1 for the Pascal Boolean type and minium of -1 and maximum of 0 for the Windows Boolean type.<br />
* '''Remedy''': Adjust arrays that have TOrdType as index.<br />
* '''svn''': 35135<br />
<br />
==== New OrdType field for tkInt64 and tkQWord ====<br />
* '''Old behavior''': MinInt64Value and MinQWordValue follow directly after start of TTypeData record.<br />
* '''New behavior''': MinInt64Value and MinQWordValue are preceeded by a OrdType field which explicitely designates them as otSQWord or otUQword respectively.<br />
* '''Reason''': To allow for 64-bit Booleans to be represented correctly the tkInt64 and tkQWord branches of TTypeData had to become part of the tkInteger (aka Ordinal) branch and thus they gained the OrdType field.<br />
* '''Remedy''': If your code relied on the relative position of MinInt64Value and MinQWordValue towards the start of the TTypeData record it needs to be adjusted.<br />
* '''svn''': 35135<br />
<br />
==== First field of TProcedureParam changed ====<br />
* '''Old behavior''': First field of TProcedureParam is called Flags and has type Byte.<br />
* '''New behavior''': First field of TProcedureParam is called ParamFlags and has type TParamFlags and there is a property called Flags of type Byte.<br />
* '''Reason''': Since TParamFlags is a set it might grow beyond the size of a Byte if more values are added to TParamFlag.<br />
* '''Remedy''': Most code should be able to use the backwards and Delphi compatible Flags property (at least if it only wants to check TParamFlag values of which the ordinal value is less than 8) other code should switch to using ParamFlags.<br />
* '''svn''': 35174<br />
<br />
==== TParamFlag extended for constref ====<br />
* '''Old behavior''': TParamFlag has no entry for constref parameters.<br />
* '''New behavior''': TParamFlag has entry pfConstRef for constref parameters.<br />
* '''Reason''': To correctly detect constref parameters they need to be marked accordingly.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices).<br />
* '''svn''': 35175<br />
<br />
==== Ranges of Boolean types adjusted ====<br />
* '''Old behavior''': ByteBool, WordBool and LongBool have a range of 0..-1.<br />
* '''New behavior''': ByteBool, WordBool and LongBool have a range of Low(LongInt) to High(LongInt).<br />
* '''Reason''': The old behavior simply cut the Low(Int64) and High(Int64) values used as ranges for the Boolean types which was wrong. That the ranges are not size dependant is Delphi compatible.<br />
* '''Remedy''': Adjust code that might have relied on the range being ''invalid''.<br />
* '''svn''': 35184<br />
<br />
==== OrdType of Boolean64 and QWordBool adjusted ====<br />
* '''Old behavior''': Boolean64 has OrdType otUByte and QWordBool has OrdType otSByte and their ranges are in MinValue and MaxValue.<br />
* '''New behavior''': Boolean64 has OrdType otUQWord with the range being in MinQWordValue and MaxQWordValue and QWordBool has OrdType otSQWord with the range being in MinInt64Value and MaxInt64Value.<br />
* '''Reason''': Both types have a size of 64-bit thus using a smaller size is incorrect.<br />
* '''Remedy''': Use the correct fields to retrieve the range boundaries of the types.<br />
* '''svn''': 35185<br />
<br />
==== All Boolean types have TypeKind tkBool ====<br />
* '''Old behavior''': Boolean has TypeKind tkBool while the other Boolean types (Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool, QWordBool) have TypeKind tkInteger.<br />
* '''New behavior''': Boolean, Boolean16, Boolean32, Boolean64, ByteBool, WordBool, LongBool and QWordBool have TypeKind tkBool.<br />
* '''Reason''': Consistency and possibility to differentiate ordinary subranges from the real Boolean types.<br />
* '''Remedy''': Check for TypeKind tkBool instead of some "magic" to detect Boolean types.<br />
* '''Note''': Since fields can only appear once in a record the tkBool branch of TTypeData was not adjusted. This has no practical consequences however as all fields of a variant record are always accessible.<br />
* '''svn''': 35186, 35187<br />
<br />
==== TParamFlag extended for hidden parameters ====<br />
* '''Old behavior''': TParamFlag has no entries for the hidden parameters (Array High, Self, Vmt, Result) of a function; SizeOf(TParamFlags) = 1<br />
* '''New behavior''': TParamFlag has entry pfHidden for hidden parameters in general and pfHigh for the high parameter of open array, pfSelf for the instance or class type, pfVmt for constructor's VMT parameter and pfResult if the result is passed as a parameter; SizeOf(TParamFlags) = 2<br />
* '''Reason''': As the plan is to use a manager based approach for Invoke() the RTL glue code should need as less knowledge as possible about calling conventions; due to this the locations of the hidden parameters needs to be known.<br />
* '''Remedy''': Adjust code that relies on the amount of elements contained in TParamFlag (e.g. case-statements or array indices) and also code that relies on the size of TParamFlags being 1 (SizeOf(TParamFlags) should be used instead).<br />
* '''svn''': 35267, 35286, 35291<br />
<br />
==== Parameters of method pointer variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of method pointer variables only listed visible parameters.<br />
* '''New behavior''': The parameters of method pointer variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
==== Parameters of procedure variables contain hidden parameters ====<br />
* '''Old behavior''': The parameters of procedure variables only listed visible parameters.<br />
* '''New behavior''': The parameters of procedure variables list all parameters.<br />
* '''Reason''': Makes the implementation of function call managers more stable in case the ABI should change.<br />
* '''Remedy''': Depending on your code either handle the new parameters or check for ''pfHidden'' in the parameter flags and ignore them.<br />
* '''svn''': 39885<br />
<br />
=== Unit changes ===<br />
<br />
==== SysUtils ====<br />
* '''Old behaviour:''' faSymlink had the numerical value $40. This was wrong on windows, and not compatible with Delphi.<br />
* '''New behaviour:''' faSymlink has the numerical value $400. Correct on windows.<br />
* '''Reason for change:''' Wrong functionality and Delphi compatibility.<br />
* '''Remedy:''' If you are using the old numerical constant $40, simply use faSymlink instead.<br />
* '''svn:''' r33340<br />
<br />
==== Classes.TList auto-growth ====<br />
* '''Old behaviour:''' Lists with number of elements greater than 127 was expanded by 1/4 of its current capacity<br />
* '''New behaviour:''' Adds two new thresholds. If number of elements is greater than 128 MB then list is expanded by constant amount of 16 MB elements (corresponds to 1/8 of 128 MB). If number of elements is greater then 8 MB then list is expanded by 1/8 of its current capacity.<br />
* '''Reason for change:''' Avoid out-of-memory when very large lists are expanded<br />
* '''svn:''' 34462<br />
<br />
==== Math Min/Max ====<br />
* '''Old behaviour:''' Mixing of QWord and Int64 was possible as there was no QWord overload. However the result might have been wrong.<br />
* '''New behaviour:''' Overload for QWord exists now but mixed calls with Int64/QWord cause a compiler error.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Apply an explicit typecast to one of the parameters so both are of the same type.<br />
* '''svn:''' 39995<br />
<br />
==== StrUtils AnsiStartsText/AnsiEndsText ====<br />
* '''Old behaviour:''' AnsiStartsText or AnsiEndsText would return false for empty substring. This is not in line with Delphi, which returns true.<br />
* '''New behaviour:''' AnsiStartsText or AnsiEndsText now return True for empty substring.<br />
* '''Reason for change:''' Delphi compatibility.<br />
* '''Remedy:''' Check explicitly for empty string if you counted on the old behaviour.<br />
* '''svn:''' 38768<br />
<br />
==== Types IStream interface and Classes TStreamAdapter ====<br />
* '''Old behaviour:''' IStream Interface (classes unit and jwa units) used Int64 for various out parameters.<br />
* '''New behaviour:''' IStream Interface (classes unit and jwa units) use QWord for various out parameters.<br />
* '''Reason for change:''' The MS Headers use largeUint, which translates to QWord. The headers were for an old version of Delphi, which didn't know QWord.<br />
* '''Remedy:''' If a class implementing this interface no longer compiles, adapt the signature of the interface's methods so they conform to the new definition.<br />
* '''svn:''' 32820 and 35542<br />
<br />
==== Baseunix (Linux only) ====<br />
* '''Old behaviour:''' stat was an union, with one side the proper posix fieldnames, and the other deprecated, simplified 1.0.x fieldnames. The 1.0.x were already marked as deprecated for 2 major cycles.<br />
* '''New behaviour:''' Deprecated 1.0.x fieldnames removed.<br />
* '''Reason for change:''' Left over 1.0.x transition feature. Incompatible with other *nix ports. <br />
* '''Remedy:''' Update fieldnames <br />
* '''svn:''' 39644 and 39655<br />
<br />
==== Classes TStrings.LoadFromStream/File encoding handling ====<br />
* '''Old behaviour:''' The LoadFromStream call totally ignored the encoding of a file, loading it from a stream without regard for encoding, unless an encoding was specified. <br />
* '''New behaviour:''' There is an overloaded call with a Boolean parameter 'IgnoreEncoding' which determines whether the encoding should be taken into account or not. By default, this parameter is False, meaning that LoadFromStream with just a stream as argument now calls the encoding-aware version of LoadFromStream, passing it an encoding of Nil, which mean the default encoding will be used.<br />
* '''Reason for change:''' Delphi compatibility, and the corresponding changes in TStringStream constructors.<br />
* '''Remedy:''' The old behaviour can be restored by setting the IgnoreEncoding parameter to 'True'.<br />
* '''svn:''' 37962 and 37965<br />
<br />
===== TStringStream now observes system encoding =====<br />
* '''Old behaviour''': TStringStream copied bytes as-is from the string specified in the constructor. <br />
* '''New behaviour''': Now bytes are fetched from the string using the encoding of the string.<br />
* '''Reason:''' Delphi-compatibility<br />
* '''Remedy:''' Pass a string with the correct encoding to TStringStream<br />
* '''svn''': 36758<br />
<br />
==== DB ====<br />
===== TParam.LoadFromFile sets share mode to fmShareDenyWrite =====<br />
* '''Old behaviour''': TFileStream.Create(FileName, fmOpenRead) was used, which has blocked subsequent access (also read-only) to same file<br />
* '''New behaviour''': TFileStream.Create(FileName, fmOpenRead+fmShareDenyWrite) is used, which does not block read access to same file<br />
* '''Remedy''': If your application requires exclusive access to file specify fmShareExclusive<br />
<br />
===== CodePage aware TStringField and TMemoField =====<br />
* '''Old behaviour''': These character fields were agnostic to data they presented. IOW when we read content of such field using AsString data was passed from internal character buffer to string as is without any conversion.<br />
* '''New behaviour''': When those fields are created there can be specified CodePage (if none specified CP_ACP is assumed), which defines encoding of character data presented by this field. In case of sqlDB TSQLConnection.CharSet is usualy used. When we read content of such field using AsString character data are translated from fields code page to CP_ACP. Same translation happens when we read content using AsUTF8String (translation to CP_UTF8) or AsUnicodeString (translation to UTF-16). This change reflects CodePage aware strings introduced in FPC 3.<br />
<br />
===== ODBC headers on Unix platforms defaults to 3.52 version =====<br />
* '''Old behaviour''': default was ODBCVER $0351. SQLLEN/SQLULEN was 32 bit on 64 bit Unix platforms.<br />
* '''New behaviour''': default is ODBCVER $0352. SQLLEN/SQLULEN is 64 bit on 64 bit Unix platforms. So it affects some ODBC API functions, which use parameters of this type (it affects also TODBCConnection of course). Also installed unixODBC/iODBC package must match this (in case of unixODBC you can check it using: "odbcinst -j" SQLLEN/SQLULEN must be 8 bytes on 64 bit platform).<br />
<br />
===== TBlobData opaque type reworked to TBytes =====<br />
* '''Old behaviour''': TBlobData was declared as Ansistring<br />
* '''New behaviour''': TBlobData is declared as TBytes <br />
* '''Reason for change''': Delphi compatibility. Also helps to avoid possible code page recodings.<br />
* '''Remedy''': If your application used TBlobData as a string, you can use AsString for parameters, or convert to TBytes.<br />
<br />
==== FGL ====<br />
===== Declaration of type TTypeList changed =====<br />
* '''Old behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''array[0..GMaxListSize] of T''.<br />
* '''New behavior''': The type ''TTypeList'' of the generic classes ''TFPGList<>'', ''TFPGObjectList<>'' and ''TFPGInterfacedObjectList<>'' is declared as ''PT''.<br />
* '''Reason''': The way ''GMaxListSize'' was declared this could lead to too large static array types so that compilation aborted with a ''Data segment too large'' error. This also might have lead to incorrect range errors if range checking was turned on. As FPC supports indexed access to pointer types potential type problems when using the ''List'' property should be minimal.<br />
* '''Remedy''': If your application relies on ''PTypeList'' to be a static array type (instead of merely being indexable like an array) then you'll need to adjust your code.<br />
* '''svn''': 39464<br />
<br />
==== objcbase ====<br />
* '''Old behaviour''': The Objective-C BOOL type was represented by objcbase.BOOL, which was the same as a Pascal boolean on all platforms.<br />
* '''New behaviour''': The Objective-C BOOL type is now represented by objcbase.ObjCBOOL, which maps to a boolean type that always corresponds to the one used in Objective-C (it differs on some platforms)<br />
* '''Reason''': The renaming was to prevent name clashes, and the type definition change was to fix interfacing issues between Objective-Pascal and Objective-C<br />
* '''Remedy''': change all uses of Boolean and BOOL in Objective-Pascal method definitions to ObjCBool.<br />
* '''svn''': 42483<br />
<br />
==== SimpleIPC ====<br />
* '''Old behaviour''': ReadMessage is a procedure.<br />
* '''New behaviour''': ReadMessage is a function, returning a boolean, telling you whether a message was actually read.<br />
* '''Reason''': Provide more information to the user. <br />
* '''Remedy''': Handle the result if necessary. (if you used OnMessage, no change is necessary)<br />
* '''svn''': 36916<br />
<br />
<br />
==== Process Unit ====<br />
<br />
===== Runcommand =====<br />
* '''Old behaviour:''' Runcommand had a few short sleeps to reduce CPU usage when the called process ran long.<br />
* '''New behaviour:''' Runcommand defaults to no sleep unless poRunIdle is passed to the default parameter with process options.<br />
* '''Reason for change:''' Applications that ran binaries to quickly obtain information were stalled by the pauses for no good reason. Servicing both short and long running binaries adequately without additional info seemed impossible due to slightly differing OS behaviours in pipe reading.<br />
* '''Remedy:''' For short living processes that start up quickly: do nothing. For long running processes, pass poRunIdle as process option.<br />
* '''svn:''' this changes was merged post RC1<br />
<br />
===== pnoconsole on Windows =====<br />
* '''Old behaviour:''' On Windows, ponoconsole mapped to winapi DETACH_PROCESS which still created standard input/output/error handles.<br />
* '''New behaviour:''' ponewconsole maps to CREATE_NO_WINDOW, which doesn't create input/output/error handles. A new option podetached allows for DETACH_PROCESS<br />
* '''Reason for change:''' ponoconsole still created a window in cases. (mantis [https://bugs.freepascal.org/view.php?id=32055 bug 32055]). <br />
* '''Remedy:''' If you try to hide the console but still need stdin/stdout handles, then ponoconsole no longer works. You could try podetached. See also [https://forum.lazarus.freepascal.org/index.php/topic,49631.msg360286.html#msg360286 podetached forum thread]<br />
* '''svn:''' the podetached option was created post RC1<br />
<br />
== Linux/Android platforms ==<br />
<br />
=== GNU Binutils 2.19.1 or later are required by default ===<br />
* '''Old behaviour''': The compiler invocation of the linker always resulted in a warning stating "did you forget -T?"<br />
* '''New behaviour''': The compiler now uses a different way to invoke the linker, which prevents this warning, but this requires functionality that is only available in GNU Binutils 2.19 and later.<br />
* '''Reason''': Get rid of the linker warning, which was caused by the fact that we used the linker in an unsupported way (and which hence occasionally caused issues).<br />
* '''Remedy''': If you have a system with an older version of GNU Binutils, you can use the new ''-X9'' command line parameter to make the compiler revert to the old behaviour. You will not be able to (easily) bootstrap the new version of FPC on such a system though, so use another system with a more up-to-date version of GNU Binutils for that.<br />
<br />
=== Stack alignment on Linux/i386 ===<br />
* '''Old behaviour''': The stack alignment for Linux/i386 was 4 bytes.<br />
* '''New behaviour''': The stack alignment for Linux/i386 is 16 bytes.<br />
* '''Reason''': Compatibility with the current Linux/i386 ABI and code generated by other Linux/i386 compilers.<br />
* '''Remedy''': This change will generally only impact inline assembly code that calls subroutines. If you have such code, ensure the stack is aligned to a multiple of 16 bytes before calling any subroutine. You may also have to realign the stack to 16 bytes after routines return in case they use a calling convention whereby the callee removes any stack arguments.<br />
<br />
== i386 platforms ==<br />
<br />
=== -Ooasmcse/{$optimization asmcse} has been removed ===<br />
* '''Old behaviour''': The compiler contained an assembler common subexpression elimination pass for the i386 platform.<br />
* '''New behaviour''': This optimisation pass has been removed from the compiler.<br />
* '''Reason''': That pass has been disabled by default since several releases because it hadn't been maintained, and it generated buggy code when combined with newer optimisation passes.<br />
* '''Remedy''': Don't use -Ooasmcse/{$optimization asmcse} anymore.<br />
<br />
== i8086 platforms ==<br />
<br />
=== the codepointer type has been changed in the small and compact memory models ===<br />
<br />
* '''Old behaviour''': The compiler used the NearPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''New behaviour''': The compiler now uses the NearCsPointer type for getting the address of procedures, functions and labels in the small and compact memory models.<br />
* '''Reason''': Using NearCsPointer more accurately represents the fact that code lives in a separate segment in the small memory model and also allows reading the machine code of a procedure, which might be useful in low level code.<br />
* '''Remedy''': If your program uses the small memory model and needs any kind of fixing, you're very likely to get compile time type checking errors, since the Pointer and CodePointer types are no longer compatible. To fix these, change all your pointers that point to code to CodePointer instead of Pointer. Alternatively, if your program is really small (code+data<=64k), you can switch to the tiny memory model, where the Pointer and CodePointer types are still compatible. If your program uses the compact memory model, it is unlikely to get any sort of breakage, since the Pointer and CodePointer types were already incompatible in this memory model.<br />
* '''svn''': 38691<br />
<br />
== Darwin/macOS platforms ==<br />
<br />
=== Default Target macOS version ===<br />
* '''Old behaviour''': The default target version for the i386 (Intel 32 bits) platform was Mac OS X 10.4 (Tiger), and for the x86-64 (Intel 64 bits) was Mac OS X 10.5 (Leopard).<br />
* '''New behaviour''': The default target version for both the i386 (Intel 32 bits) and x86-64 (Intel 64 bits) platforms is now OS X 10.8 (Mountain Lion).<br />
* '''Reason''': On macOS 10.14, installing the command line tools no longer places the crt*.o files required when targeting the older targets in the same location as before, resulting in the need for custom command line options and modifications to fpc.cfg.<br />
* '''Remedy''': If you wish to target those earlier operating system versions, use the ''-WM10.4'' resp. ''-WM10.5'' command line parameters of the compiler, and if necessary point it to an SDK that still contains support for those operating system versions with the ''-XR/path/to/SDK'' parameter (and, if necessary, to an assembler/linker that supports removed architectures with ''-FD/path/to/clang_and_ld'').<br />
* '''svn''': 43374<br />
<br />
=== Darwin/i386 and calling conventions whereby the callee removes stack parameters ===<br />
* '''Old behaviour''': The Darwin/i386 code generator treated all calling conventions as "caller removes stack parameters", even for calling conventions where this is normally not the case.<br />
* '''New behaviour''': The Darwin/i386 code generator correctly handles calling conventions whereby the callee removes the stack parameters. In particular, this changes the behaviour for the ''register'', ''stdcall'', ''safecall'', and ''pascal'' calling conventions.<br />
* '''Reason''': Respect calling conventions, compatibility with other platforms and compilers.<br />
* '''Remedy''': If you have inline assembly code that dealt with this special behaviour of Darwin/i386 under older FPC versions, you can disable it for FPC 3.2 and later. Darwin/i386 now behaves according to the same (new) rules as [[User_Changes_3.2#Stack_alignment_on_Linux.2Fi386|Linux/i386]].<br />
* '''svn''': r43650<br />
<br />
== Windows platforms ==<br />
<br />
=== GNU Binutils 2.25 or later are required by default ===<br />
* '''Old behaviour''': If the binary of a unit contains too many sections ( > $7fff) it fails to compile, due to the binary format not supporting that many sections.<br />
* '''New behaviour''': If the binary of a unit contains many sections ( > $7fff) it will be compiled using the BigObj format of COFF.<br />
* '''Reason''': Some units (e.g. ''packages\odata\src\sharepoint.pp'') got so large that they could no longer be compiled using the normal COFF format. The internal assembler and linker can handle this format as can the GNU binutils, but only starting from 2.25 on.<br />
* '''Remedy''': If you compile with the binutils instead of using the internal assembler/linker then either use an up to date version of the binutils (>= 2.25) or if you really need to use an older version, then pass -a5 which will disable the use of BigObj COFF files, though you'll then not be able to build the whole FPC distribution nor will you be able to link to such big units.<br />
<br />
== Previous release notes ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC User Changes by release]]<br />
[[Category:Release Notes]]<br />
[[Category:Troubleshooting]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=FPC_New_Features_Trunk&diff=137414FPC New Features Trunk2020-06-25T20:57:33Z<p>PascalDragon: Documented IsConstValue intrinsic</p>
<hr />
<div>== About this page ==<br />
<br />
Below you can find a list of new features introduced since the [[FPC_New_Features_3.2|next planned release]], along with some background information and examples. Note that since svn trunk is by definition still under development, some of the features here may still change before they end up in a release version.<br />
<br />
A list of changes that may break existing code can be found [[User Changes Trunk|here]].<br />
<br />
== All systems ==<br />
<br />
=== Language ===<br />
<br />
==== Support for "volatile" intrinsic ====<br />
* '''Overview''': A '''volatile''' intrinsic has been added to indicate to the code generator that a particular load from or store to a memory location must not be removed.<br />
* '''Notes''': Delphi uses an attribute rather than an intrinsic. Such support will be added once support for attributes is available in FPC. An intrinsic that applies only to a specific memory access also has the advantages outlined in https://lwn.net/Articles/233482/<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tmt1.pp<br />
* '''svn''': 40465<br />
<br />
==== Support for "noinline" modifier ====<br />
* '''Overview''': A '''noinline''' modifier has been added that can be used to prevent a routine from ever being inlined (even by automatic inlining).<br />
* '''Notes''': Mainly added for internal compiler usage related to LLVM support.<br />
* '''svn''': 41198<br />
<br />
==== Support for multiple active helpers per type ====<br />
* '''Overview''': With the modeswitch ''multihelpers'' multiple helpers for a single type can be active at once. If a member of the type is accessed it's first checked in all helpers that are in scope in reverse order before the extended type itself is checked.<br />
* '''Examples''': All tests with the name ''tmshlp*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''svn''': 42026<br />
<br />
==== Support for custom attributes ====<br />
* '''Overview''': Custom attributes allow to decorate types and published properties of classes to be decorated with additional metadata. The metadata are by itself descendants of ''TCustomAttribute'' and can take additional parameters if the classes have a suitable constructor to take these parameters. This feature requires the new modeswitch ''PrefixedAttributes''. This modeswitch is active by default in modes ''Delphi'' and ''DelphiUnicode''. Attributes can be queried using the ''TypInfo'' or ''Rtti'' units.<br />
* '''Notes''': More information can be seen in the [https://lists.freepascal.org/pipermail/fpc-announce/2019-July/000612.html announcement mail] and [[Custom_Attributes|Custom Attributes]]<br />
* '''svn''': 42356 - 42411<br />
* '''Example''':<br />
<syntaxhighlight lang="pascal"><br />
program tcustomattr;<br />
<br />
{$mode objfpc}{$H+}<br />
{$modeswitch prefixedattributes}<br />
<br />
type<br />
TMyAttribute = class(TCustomAttribute)<br />
constructor Create;<br />
constructor Create(aArg: String);<br />
constructor Create(aArg: TGUID);<br />
constructor Create(aArg: LongInt);<br />
end;<br />
<br />
{$M+}<br />
[TMyAttribute]<br />
TTestClass = class<br />
private<br />
fTest: LongInt;<br />
published<br />
[TMyAttribute('Test')]<br />
property Test: LongInt read fTest;<br />
end;<br />
{$M-}<br />
<br />
[TMyAttribute(1234)]<br />
[TMy('Hello World')]<br />
TTestEnum = (<br />
teOne,<br />
teTwo<br />
);<br />
<br />
[TMyAttribute(IInterface), TMy(42)]<br />
TLongInt = type LongInt;<br />
<br />
constructor TMyAttribute.Create;<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: String);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: LongInt);<br />
begin<br />
end;<br />
<br />
constructor TMyAttribute.Create(aArg: TGUID);<br />
begin<br />
end;<br />
<br />
begin<br />
<br />
end. <br />
</syntaxhighlight><br />
<br />
==== Support for constant parameters in generics ====<br />
* '''Overview''': Generic types and routines can now be declared with constants as parameters which function as untyped constants inside the generic. However these generic parameters have a type which allows the author of the generic to restrict the possible values for the constant. Only constant types that can also be used for untyped constants can be used.<br />
* '''Examples''': All tests with the name ''tgenconst*.pp'' in https://svn.freepascal.org/svn/fpc/trunk/tests/test<br />
* '''Notes''':<br />
** This feature is not Delphi compatible, but can be used in mode ''Delphi'' as well<br />
** More information is available in the [https://lists.freepascal.org/pipermail/fpc-devel/2020-April/042708.html announcement mail].<br />
* '''svn''': 45080<br />
<br />
==== Support for "IsConstValue" intrinsic ====<br />
* '''Overview''': An ''IsConstValue'' intrinsic has been added to check whether a provided values is considered a constant value. This is mainly useful inside inlined functions to manually improve the generated code if a constant is encountered.<br />
* '''Notes''':<br />
** This function returns a constant Boolean value and is Delphi compatible.<br />
** Typed constants are ''not'' considered constants (Delphi compatible and also compatible with the usual modus operandi regarding typed constants).<br />
* '''Example''': https://svn.freepascal.org/svn/fpc/trunk/tests/test/tisconstvalue2.pp<br />
* '''svn''': 45695<br />
<br />
=== Units ===<br />
<br />
==== Registry unit ====<br />
*'''Overview''': The TRegistry class was made to be fully Unicode capable.<br />
*'''Notes''': <br />
**All public and protected methods (the public API) that used string parameters now default to use UnicodeString parameters.<br />
**For all these methods overloads exist using String parameters (these call their UnicodeString counterparts).<br />
**Methods using TStrings have counterparts using TUnicodeStringArray, and ReadStringList/WriteStringList let you specify if the TStrings should be treated as UTF8 encoded.<br />
**The public API of TXMLRegistry was changed to use UnicodeString everywhere, without having String overloads. TXMLRegistry interfaces with a TXMLDocument structure internally, which uses DOMString (which in turn is an alias to WideString).<br />
**TRegIniFile and TRegistryIniFile have been deprecated on non-Windows platforms.<br />
**The public API of TRegIniFile has not been changed.<br />
*'''More information''': https://lists.freepascal.org/pipermail/fpc-devel/2019-February/040446.html<br />
*'''svn''': r41784<br />
<br />
== New compiler targets ==<br />
<br />
=== Support for code generation through LLVM ===<br />
* '''Overview''': The compiler now has a code generator that generates LLVM bitcode.<br />
* '''Notes''': LLVM still requires target-specific support and modifications in the compiler. Initially, the LLVM code generator only works when targeting Darwin/x86-64, Linux/x86-64, Linux/ARMHF and Linux/AArch64.<br />
* '''More information''': [[LLVM]]<br />
* '''svn''': 42260<br />
<br />
== New Features from other versions ==<br />
{{Navbar Lazarus Release Notes}}<br />
<br />
[[Category:FPC New Features by release]]<br />
[[Category:Release Notes]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=MSX-DOS&diff=137009MSX-DOS2020-06-06T18:21:25Z<p>PascalDragon: Output name is .com by default now</p>
<hr />
<div>MSX-DOS is a CP/M-DOS-like operating developed by Microsoft for the Z80 based MSX computer.<br />
<br />
Starting with revision r45600 Free Pascal has initial support for generating code for MSX-DOS.<br />
<br />
== Overview ==<br />
<br />
The compiler generates flat COM files which reside in the Transient Program Area (TPA) of the memory that reaches from $100 to the address of the DOS (which might start at something like $DEF0 or so). The top of the TPA is the place of the stack (at program start the top of the stack points below the start of the DOS) and FPC reserves an area for the heap inside the TPA as well. Thus the size for the program code and data is currently restricted to the remaining size. Mechanisms for (transparently) utilizing the slot mechanisms of the MSX need yet to be researched. Due to this restriction extreme care needs to be taken when linking in code as the limit can be reached quickly and quietly.<br />
<br />
At least MSX-DOS 2.0 or newer is required.<br />
<br />
In addition FPC produces rather verbose code compared to e.g. Turbo Pascal 3.0. It needs to be seen whether this can be improved in the future.<br />
<br />
As of revision r45600 the ''System'' unit is supported, but neither the ''DOS'' nor the ''SysUtils'' unit are. The ''ObjPas'' and ''ISO7185'' units are compiled though not yet tested. Console as well as File I/O are implemented, though only the former is tested due to apparent bugs in the code generator.<br />
<br />
== Building the compiler ==<br />
<br />
First of you need the ''ihxutil'' utility. For this simply do a build of FPC for your host target which will build the utility as well and the resulting binary will then reside in ''utils/ihxutil/bin/<HOSTCPU>-<HOSTOS>''. <br />
<br />
Currently a ''make all'' in the top level directory of the FPC sources does not fully succeed, but it works enough that the resulting compiler and RTL can be used, so use the following:<br />
<br />
make all OS_TARGET=msxdos CPU_TARGET=z80 OPT=-CX<br />
<br />
== Building a program ==<br />
<br />
Once you've build the compiler and RTL you can then build programs using the following command:<br />
<br />
./compiler/ppcrossz80 -n -Tmsxdos -Furtl/units/z80-msxdos -viwn -FE<OUTPUTDIR> -FDutils/ihxutil/bin/<HOSTCPU>-<HOSTOS> -CX -XX file.pp<br />
<br />
The options ''-CX -XX'' are very important to enable smartlinking to have even remotely a chance to fit the program into the available space.<br />
<br />
If you place the ''ihxutil'' utility into a directory reachable by the PATH environment variable you can leave out the ''-FD...'' parameter.<br />
<br />
== Setting heap and stack size ==<br />
<br />
The default heap size is 256 Byte and the default stack size is 1024. This can be changed using the ''$MEMORY'' directive as documented [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 here]. The format of the directive is<br />
<br />
{$MEMORY StackSize,HeapSize}<br />
<br />
== Known problems ==<br />
<br />
This is a list of currently known problems:<br />
<br />
* Parameters are not correctly initialized (code generator problem?)<br />
* Assign() does not correctly set the filename (code generator problem?)<br />
* HexStr() does not result in correct hex strings (code generator problem?)<br />
* MkDir(), ChDir(), RmDir() are not implemented (MSX-DOS does not seem to support these?)<br />
<br />
== Differences to Turbo Pascal 3.0 ==<br />
<br />
A common Pascal compiler for MSX is Turbo Pascal 3.0. There are a few significant differences between FPC and that version of Turbo Pascal (even if mode ''TP'' is used). In general a look at the [https://www.freepascal.org/docs-html/current/ref/ref.html Language Reference Guide] and maybe also the [https://www.freepascal.org/docs-html/current/prog/prog.html Programmer's Guide] of FPC is suggested.<br />
<br />
=== Support for units ===<br />
<br />
Turbo Pascal 3.0 did not yet support the concept of units that premiered in newer versions of Turbo Pascal. FPC however does support them, so you can put your code into separate units. Though you can still use include files if you want to, but units like ''System'' will be used automatically.<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 here]<br />
<br />
=== Inline assembly ===<br />
<br />
FPC does not support Turbo Pascal's ''Inline()'' intrinsic to provide inline assembly. Instead FPC provides a mnemonic based inline assembly that is started with '''asm''' and ended with '''end'''. Whole functions can be declared such if they're marked with the '''assembler''' directive (plus probably '''nostackframe''' to avoid the compiler setting up a stackframe).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refch18.html#x232-25400018 here]<br />
<br />
=== Inlining ===<br />
<br />
FPC can inline functions declared with the '''inline''' directive (there are some restrictions though, e.g. no assembly blocks allowed, no open array parameters and a few others), meaning that a call is avoided at the expense of potentially bloating the binary size, though it might lead to better optimized code (especially if constant parameters are used).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refsu73.html#x191-21300014.10.4 here]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=MSX-DOS&diff=137008MSX-DOS2020-06-06T18:16:11Z<p>PascalDragon: Added a list of known problems</p>
<hr />
<div>MSX-DOS is a CP/M-DOS-like operating developed by Microsoft for the Z80 based MSX computer.<br />
<br />
Starting with revision r45600 Free Pascal has initial support for generating code for MSX-DOS.<br />
<br />
== Overview ==<br />
<br />
The compiler generates flat COM files which reside in the Transient Program Area (TPA) of the memory that reaches from $100 to the address of the DOS (which might start at something like $DEF0 or so). The top of the TPA is the place of the stack (at program start the top of the stack points below the start of the DOS) and FPC reserves an area for the heap inside the TPA as well. Thus the size for the program code and data is currently restricted to the remaining size. Mechanisms for (transparently) utilizing the slot mechanisms of the MSX need yet to be researched. Due to this restriction extreme care needs to be taken when linking in code as the limit can be reached quickly and quietly.<br />
<br />
At least MSX-DOS 2.0 or newer is required.<br />
<br />
In addition FPC produces rather verbose code compared to e.g. Turbo Pascal 3.0. It needs to be seen whether this can be improved in the future.<br />
<br />
As of revision r45600 the ''System'' unit is supported, but neither the ''DOS'' nor the ''SysUtils'' unit are. The ''ObjPas'' and ''ISO7185'' units are compiled though not yet tested. Console as well as File I/O are implemented, though only the former is tested due to apparent bugs in the code generator.<br />
<br />
== Building the compiler ==<br />
<br />
First of you need the ''ihxutil'' utility. For this simply do a build of FPC for your host target which will build the utility as well and the resulting binary will then reside in ''utils/ihxutil/bin/<HOSTCPU>-<HOSTOS>''. <br />
<br />
Currently a ''make all'' in the top level directory of the FPC sources does not fully succeed, but it works enough that the resulting compiler and RTL can be used, so use the following:<br />
<br />
make all OS_TARGET=msxdos CPU_TARGET=z80 OPT=-CX<br />
<br />
== Building a program ==<br />
<br />
Once you've build the compiler and RTL you can then build programs using the following command:<br />
<br />
./compiler/ppcrossz80 -n -Tmsxdos -Furtl/units/z80-msxdos -viwn -FE<OUTPUTDIR> -o<NAME>.com -FDutils/ihxutil/bin/<HOSTCPU>-<HOSTOS> -CX -XX file.pp<br />
<br />
The options ''-CX -XX'' are very important to enable smartlinking to have even remotely a chance to fit the program into the available space.<br />
<br />
If you place the ''ihxutil'' utility into a directory reachable by the PATH environment variable you can leave out the ''-FD...'' parameter.<br />
<br />
== Setting heap and stack size ==<br />
<br />
The default heap size is 256 Byte and the default stack size is 1024. This can be changed using the ''$MEMORY'' directive as documented [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 here]. The format of the directive is<br />
<br />
{$MEMORY StackSize,HeapSize}<br />
<br />
== Known problems ==<br />
<br />
This is a list of currently known problems:<br />
<br />
* Parameters are not correctly initialized (code generator problem?)<br />
* Assign() does not correctly set the filename (code generator problem?)<br />
* HexStr() does not result in correct hex strings (code generator problem?)<br />
* MkDir(), ChDir(), RmDir() are not implemented (MSX-DOS does not seem to support these?)<br />
<br />
== Differences to Turbo Pascal 3.0 ==<br />
<br />
A common Pascal compiler for MSX is Turbo Pascal 3.0. There are a few significant differences between FPC and that version of Turbo Pascal (even if mode ''TP'' is used). In general a look at the [https://www.freepascal.org/docs-html/current/ref/ref.html Language Reference Guide] and maybe also the [https://www.freepascal.org/docs-html/current/prog/prog.html Programmer's Guide] of FPC is suggested.<br />
<br />
=== Support for units ===<br />
<br />
Turbo Pascal 3.0 did not yet support the concept of units that premiered in newer versions of Turbo Pascal. FPC however does support them, so you can put your code into separate units. Though you can still use include files if you want to, but units like ''System'' will be used automatically.<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 here]<br />
<br />
=== Inline assembly ===<br />
<br />
FPC does not support Turbo Pascal's ''Inline()'' intrinsic to provide inline assembly. Instead FPC provides a mnemonic based inline assembly that is started with '''asm''' and ended with '''end'''. Whole functions can be declared such if they're marked with the '''assembler''' directive (plus probably '''nostackframe''' to avoid the compiler setting up a stackframe).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refch18.html#x232-25400018 here]<br />
<br />
=== Inlining ===<br />
<br />
FPC can inline functions declared with the '''inline''' directive (there are some restrictions though, e.g. no assembly blocks allowed, no open array parameters and a few others), meaning that a call is avoided at the expense of potentially bloating the binary size, though it might lead to better optimized code (especially if constant parameters are used).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refsu73.html#x191-21300014.10.4 here]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=MSX-DOS&diff=137007MSX-DOS2020-06-06T18:13:55Z<p>PascalDragon: -Tmsxdos parameter is required</p>
<hr />
<div>MSX-DOS is a CP/M-DOS-like operating developed by Microsoft for the Z80 based MSX computer.<br />
<br />
Starting with revision r45600 Free Pascal has initial support for generating code for MSX-DOS.<br />
<br />
== Overview ==<br />
<br />
The compiler generates flat COM files which reside in the Transient Program Area (TPA) of the memory that reaches from $100 to the address of the DOS (which might start at something like $DEF0 or so). The top of the TPA is the place of the stack (at program start the top of the stack points below the start of the DOS) and FPC reserves an area for the heap inside the TPA as well. Thus the size for the program code and data is currently restricted to the remaining size. Mechanisms for (transparently) utilizing the slot mechanisms of the MSX need yet to be researched. Due to this restriction extreme care needs to be taken when linking in code as the limit can be reached quickly and quietly.<br />
<br />
At least MSX-DOS 2.0 or newer is required.<br />
<br />
In addition FPC produces rather verbose code compared to e.g. Turbo Pascal 3.0. It needs to be seen whether this can be improved in the future.<br />
<br />
As of revision r45600 the ''System'' unit is supported, but neither the ''DOS'' nor the ''SysUtils'' unit are. The ''ObjPas'' and ''ISO7185'' units are compiled though not yet tested. Console as well as File I/O are implemented, though only the former is tested due to apparent bugs in the code generator.<br />
<br />
== Building the compiler ==<br />
<br />
First of you need the ''ihxutil'' utility. For this simply do a build of FPC for your host target which will build the utility as well and the resulting binary will then reside in ''utils/ihxutil/bin/<HOSTCPU>-<HOSTOS>''. <br />
<br />
Currently a ''make all'' in the top level directory of the FPC sources does not fully succeed, but it works enough that the resulting compiler and RTL can be used, so use the following:<br />
<br />
make all OS_TARGET=msxdos CPU_TARGET=z80 OPT=-CX<br />
<br />
== Building a program ==<br />
<br />
Once you've build the compiler and RTL you can then build programs using the following command:<br />
<br />
./compiler/ppcrossz80 -n -Tmsxdos -Furtl/units/z80-msxdos -viwn -FE<OUTPUTDIR> -o<NAME>.com -FDutils/ihxutil/bin/<HOSTCPU>-<HOSTOS> -CX -XX file.pp<br />
<br />
The options ''-CX -XX'' are very important to enable smartlinking to have even remotely a chance to fit the program into the available space.<br />
<br />
If you place the ''ihxutil'' utility into a directory reachable by the PATH environment variable you can leave out the ''-FD...'' parameter.<br />
<br />
== Setting heap and stack size ==<br />
<br />
The default heap size is 256 Byte and the default stack size is 1024. This can be changed using the ''$MEMORY'' directive as documented [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 here]. The format of the directive is<br />
<br />
{$MEMORY StackSize,HeapSize}<br />
<br />
== Differences to Turbo Pascal 3.0 ==<br />
<br />
A common Pascal compiler for MSX is Turbo Pascal 3.0. There are a few significant differences between FPC and that version of Turbo Pascal (even if mode ''TP'' is used). In general a look at the [https://www.freepascal.org/docs-html/current/ref/ref.html Language Reference Guide] and maybe also the [https://www.freepascal.org/docs-html/current/prog/prog.html Programmer's Guide] of FPC is suggested.<br />
<br />
=== Support for units ===<br />
<br />
Turbo Pascal 3.0 did not yet support the concept of units that premiered in newer versions of Turbo Pascal. FPC however does support them, so you can put your code into separate units. Though you can still use include files if you want to, but units like ''System'' will be used automatically.<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 here]<br />
<br />
=== Inline assembly ===<br />
<br />
FPC does not support Turbo Pascal's ''Inline()'' intrinsic to provide inline assembly. Instead FPC provides a mnemonic based inline assembly that is started with '''asm''' and ended with '''end'''. Whole functions can be declared such if they're marked with the '''assembler''' directive (plus probably '''nostackframe''' to avoid the compiler setting up a stackframe).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refch18.html#x232-25400018 here]<br />
<br />
=== Inlining ===<br />
<br />
FPC can inline functions declared with the '''inline''' directive (there are some restrictions though, e.g. no assembly blocks allowed, no open array parameters and a few others), meaning that a call is avoided at the expense of potentially bloating the binary size, though it might lead to better optimized code (especially if constant parameters are used).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refsu73.html#x191-21300014.10.4 here]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=MSX-DOS&diff=137006MSX-DOS2020-06-06T18:13:28Z<p>PascalDragon: FPC only supports MSX-DOS 2+ currently</p>
<hr />
<div>MSX-DOS is a CP/M-DOS-like operating developed by Microsoft for the Z80 based MSX computer.<br />
<br />
Starting with revision r45600 Free Pascal has initial support for generating code for MSX-DOS.<br />
<br />
== Overview ==<br />
<br />
The compiler generates flat COM files which reside in the Transient Program Area (TPA) of the memory that reaches from $100 to the address of the DOS (which might start at something like $DEF0 or so). The top of the TPA is the place of the stack (at program start the top of the stack points below the start of the DOS) and FPC reserves an area for the heap inside the TPA as well. Thus the size for the program code and data is currently restricted to the remaining size. Mechanisms for (transparently) utilizing the slot mechanisms of the MSX need yet to be researched. Due to this restriction extreme care needs to be taken when linking in code as the limit can be reached quickly and quietly.<br />
<br />
At least MSX-DOS 2.0 or newer is required.<br />
<br />
In addition FPC produces rather verbose code compared to e.g. Turbo Pascal 3.0. It needs to be seen whether this can be improved in the future.<br />
<br />
As of revision r45600 the ''System'' unit is supported, but neither the ''DOS'' nor the ''SysUtils'' unit are. The ''ObjPas'' and ''ISO7185'' units are compiled though not yet tested. Console as well as File I/O are implemented, though only the former is tested due to apparent bugs in the code generator.<br />
<br />
== Building the compiler ==<br />
<br />
First of you need the ''ihxutil'' utility. For this simply do a build of FPC for your host target which will build the utility as well and the resulting binary will then reside in ''utils/ihxutil/bin/<HOSTCPU>-<HOSTOS>''. <br />
<br />
Currently a ''make all'' in the top level directory of the FPC sources does not fully succeed, but it works enough that the resulting compiler and RTL can be used, so use the following:<br />
<br />
make all OS_TARGET=msxdos CPU_TARGET=z80 OPT=-CX<br />
<br />
== Building a program ==<br />
<br />
Once you've build the compiler and RTL you can then build programs using the following command:<br />
<br />
./compiler/ppcrossz80 -n -Furtl/units/z80-msxdos -viwn -FE<OUTPUTDIR> -o<NAME>.com -FDutils/ihxutil/bin/<HOSTCPU>-<HOSTOS> -CX -XX file.pp<br />
<br />
The options ''-CX -XX'' are very important to enable smartlinking to have even remotely a chance to fit the program into the available space.<br />
<br />
If you place the ''ihxutil'' utility into a directory reachable by the PATH environment variable you can leave out the ''-FD...'' parameter.<br />
<br />
== Setting heap and stack size ==<br />
<br />
The default heap size is 256 Byte and the default stack size is 1024. This can be changed using the ''$MEMORY'' directive as documented [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 here]. The format of the directive is<br />
<br />
{$MEMORY StackSize,HeapSize}<br />
<br />
== Differences to Turbo Pascal 3.0 ==<br />
<br />
A common Pascal compiler for MSX is Turbo Pascal 3.0. There are a few significant differences between FPC and that version of Turbo Pascal (even if mode ''TP'' is used). In general a look at the [https://www.freepascal.org/docs-html/current/ref/ref.html Language Reference Guide] and maybe also the [https://www.freepascal.org/docs-html/current/prog/prog.html Programmer's Guide] of FPC is suggested.<br />
<br />
=== Support for units ===<br />
<br />
Turbo Pascal 3.0 did not yet support the concept of units that premiered in newer versions of Turbo Pascal. FPC however does support them, so you can put your code into separate units. Though you can still use include files if you want to, but units like ''System'' will be used automatically.<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 here]<br />
<br />
=== Inline assembly ===<br />
<br />
FPC does not support Turbo Pascal's ''Inline()'' intrinsic to provide inline assembly. Instead FPC provides a mnemonic based inline assembly that is started with '''asm''' and ended with '''end'''. Whole functions can be declared such if they're marked with the '''assembler''' directive (plus probably '''nostackframe''' to avoid the compiler setting up a stackframe).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refch18.html#x232-25400018 here]<br />
<br />
=== Inlining ===<br />
<br />
FPC can inline functions declared with the '''inline''' directive (there are some restrictions though, e.g. no assembly blocks allowed, no open array parameters and a few others), meaning that a call is avoided at the expense of potentially bloating the binary size, though it might lead to better optimized code (especially if constant parameters are used).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refsu73.html#x191-21300014.10.4 here]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Z80&diff=137005Z802020-06-06T18:00:48Z<p>PascalDragon: Added link to MSX-DOS page</p>
<hr />
<div>== Overview ==<br />
<br />
A Z80 port is currently under development in FPC trunk:<br />
<br />
https://svn.freepascal.org/svn/fpc/trunk<br />
<br />
To check it out, use subversion:<br />
<br />
mkdir fpc-z80<br />
cd fpc-z80<br />
svn co https://svn.freepascal.org/svn/fpc/trunk fpc<br />
<br />
== Requirements ==<br />
<br />
The assembler and linker from the SDCC package are required:<br />
<br />
http://sdcc.sourceforge.net/<br />
<br />
== Targets ==<br />
<br />
=== Embedded ===<br />
<br />
The compiler produces files in the IHX format (Intel HEX Format).<br />
<br />
=== ZX Spectrum ===<br />
<br />
The compiler produces ZX Spectrum tape files in the TZX file format. They are suitable for running in emulators. An open-source emulator that works is FBZX:<br />
<br />
https://www.rastersoft.com/programas/fbzx.html<br />
<br />
ROM images for the emulator are available here:<br />
<br />
http://www.chiark.greenend.org.uk/~cjwatson/code/spectrum-roms/<br />
<br />
and here:<br />
<br />
http://www.shadowmagic.org.uk/spectrum/roms.html<br />
<br />
They are copyrighted and are not free (as in freedom), but are legally available for use in emulators (not in real hardware), and are also repackaged and redistributed in Linux repositories such as [https://rpmfusion.org/ RPMFusion - nonfree].<br />
<br />
Another emulator that works is Fuse:<br />
<br />
http://fuse-emulator.sourceforge.net/fuse.php<br />
<br />
Producing TZX files requires a tool, called '''ihxutil''', which is written in Pascal and is available in the ''utils/ihxutil'' directory of the compiler.<br />
<br />
=== MSX-DOS ===<br />
<br />
The compiler produces flat COM files that can be run from the MSX-DOS environment. Please note that you need to take extreme care that you don't link in too much code especially if you want to also include a heap and a stack. The default size for the heap is 256 and for the stack 1024 and these can be changed using the ''$MEMORY'' directive.<br />
<br />
Generating the COM files requires the '''ihxutil''' utility which is written in Pascal and is available in the ''utils/ihxutil'' directory of the Free Pascal sources.<br />
<br />
More information can be found [[MSX-DOS|here]].<br />
<br />
== Building ==<br />
<br />
Here's the build script I use:<br />
<br />
#! /bin/sh<br />
<br />
set -e<br />
<br />
FPC_Z80_DIR=/home/nickysn/tralala/fpc-z80<br />
STARTPP=fpc<br />
BINUTILSPREFIX=<br />
<br />
CROSSOPT=-O-1<br />
export CROSSOPT<br />
OPT="-CX -XXs"<br />
if [ -n "$EXTRAOPT" ]<br />
then<br />
OPT+=" $EXTRAOPT"<br />
fi<br />
export OPT<br />
export CPU_TARGET=z80<br />
export OS_TARGET=zxspectrum<br />
export OS_SOURCE=`$STARTPP -iSO`<br />
export CPU_SOURCE=`$STARTPP -iSP`<br />
<br />
cd $FPC_Z80_DIR/fpc<br />
make -j `nproc` clean PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` all PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` crossinstall PP=$FPC_Z80_DIR/fpc/compiler/ppcrossz80 INSTALL_PREFIX=$FPC_Z80_DIR/zxspectrum-snapshot BINUTILSPREFIX=$BINUTILSPREFIX<br />
<br />
Note that, if you use the SDCC package from the official Fedora repositories, you might need to replace<br />
<br />
BINUTILSPREFIX=<br />
<br />
with<br />
<br />
BINUTILSPREFIX=sdcc-<br />
<br />
When compiling programs, you should always enable smartlinking by adding these two options to the compiler:<br />
<br />
-CX -XX<br />
<br />
== Status ==<br />
<br />
As of Apr 27, 2020, the code generator is stable enough to compile the full system unit. Standard output via write/writeln works now. As of May 17, 2020, optimization level 1 also works, so you can try compiling with -O1. Note that there aren't many Z80-specific optimizations implemented yet, but enabling optimization still has some small effect. Here's a simple program that works:<br />
<br />
program Hello;<br />
var<br />
b: byte;<br />
begin<br />
Write('FPC');<br />
for b := 0 to 255 do<br />
Write(HexStr(b, 2));<br />
end.<br />
<br />
Here's what this program produces in the FBZX emulator:<br />
<br />
[[File:ZX_Spectrum_hello_world_FBZX_emulator_screenshot.png]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=MSX-DOS&diff=137004MSX-DOS2020-06-06T17:59:16Z<p>PascalDragon: Added a more detailed page about MSX-DOS</p>
<hr />
<div>MSX-DOS is a CP/M-DOS-like operating developed by Microsoft for the Z80 based MSX computer.<br />
<br />
Starting with revision r45600 Free Pascal has initial support for generating code for MSX-DOS.<br />
<br />
== Overview ==<br />
<br />
The compiler generates flat COM files which reside in the Transient Program Area (TPA) of the memory that reaches from $100 to the address of the DOS (which might start at something like $DEF0 or so). The top of the TPA is the place of the stack (at program start the top of the stack points below the start of the DOS) and FPC reserves an area for the heap inside the TPA as well. Thus the size for the program code and data is currently restricted to the remaining size. Mechanisms for (transparently) utilizing the slot mechanisms of the MSX need yet to be researched. Due to this restriction extreme care needs to be taken when linking in code as the limit can be reached quickly and quietly.<br />
<br />
In addition FPC produces rather verbose code compared to e.g. Turbo Pascal 3.0. It needs to be seen whether this can be improved in the future.<br />
<br />
As of revision r45600 the ''System'' unit is supported, but neither the ''DOS'' nor the ''SysUtils'' unit are. The ''ObjPas'' and ''ISO7185'' units are compiled though not yet tested. Console as well as File I/O are implemented, though only the former is tested due to apparent bugs in the code generator.<br />
<br />
== Building the compiler ==<br />
<br />
First of you need the ''ihxutil'' utility. For this simply do a build of FPC for your host target which will build the utility as well and the resulting binary will then reside in ''utils/ihxutil/bin/<HOSTCPU>-<HOSTOS>''. <br />
<br />
Currently a ''make all'' in the top level directory of the FPC sources does not fully succeed, but it works enough that the resulting compiler and RTL can be used, so use the following:<br />
<br />
make all OS_TARGET=msxdos CPU_TARGET=z80 OPT=-CX<br />
<br />
== Building a program ==<br />
<br />
Once you've build the compiler and RTL you can then build programs using the following command:<br />
<br />
./compiler/ppcrossz80 -n -Furtl/units/z80-msxdos -viwn -FE<OUTPUTDIR> -o<NAME>.com -FDutils/ihxutil/bin/<HOSTCPU>-<HOSTOS> -CX -XX file.pp<br />
<br />
The options ''-CX -XX'' are very important to enable smartlinking to have even remotely a chance to fit the program into the available space.<br />
<br />
If you place the ''ihxutil'' utility into a directory reachable by the PATH environment variable you can leave out the ''-FD...'' parameter.<br />
<br />
== Setting heap and stack size ==<br />
<br />
The default heap size is 256 Byte and the default stack size is 1024. This can be changed using the ''$MEMORY'' directive as documented [https://www.freepascal.org/docs-html/current/prog/progsu102.html#x110-1110001.3.19 here]. The format of the directive is<br />
<br />
{$MEMORY StackSize,HeapSize}<br />
<br />
== Differences to Turbo Pascal 3.0 ==<br />
<br />
A common Pascal compiler for MSX is Turbo Pascal 3.0. There are a few significant differences between FPC and that version of Turbo Pascal (even if mode ''TP'' is used). In general a look at the [https://www.freepascal.org/docs-html/current/ref/ref.html Language Reference Guide] and maybe also the [https://www.freepascal.org/docs-html/current/prog/prog.html Programmer's Guide] of FPC is suggested.<br />
<br />
=== Support for units ===<br />
<br />
Turbo Pascal 3.0 did not yet support the concept of units that premiered in newer versions of Turbo Pascal. FPC however does support them, so you can put your code into separate units. Though you can still use include files if you want to, but units like ''System'' will be used automatically.<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refse106.html#x216-23800016.2 here]<br />
<br />
=== Inline assembly ===<br />
<br />
FPC does not support Turbo Pascal's ''Inline()'' intrinsic to provide inline assembly. Instead FPC provides a mnemonic based inline assembly that is started with '''asm''' and ended with '''end'''. Whole functions can be declared such if they're marked with the '''assembler''' directive (plus probably '''nostackframe''' to avoid the compiler setting up a stackframe).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refch18.html#x232-25400018 here]<br />
<br />
=== Inlining ===<br />
<br />
FPC can inline functions declared with the '''inline''' directive (there are some restrictions though, e.g. no assembly blocks allowed, no open array parameters and a few others), meaning that a call is avoided at the expense of potentially bloating the binary size, though it might lead to better optimized code (especially if constant parameters are used).<br />
<br />
See also [https://www.freepascal.org/docs-html/current/ref/refsu73.html#x191-21300014.10.4 here]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Z80&diff=137003Z802020-06-06T17:29:31Z<p>PascalDragon: ihx2tzx got renamed to ihxutil</p>
<hr />
<div>== Overview ==<br />
<br />
A Z80 port is currently under development in FPC trunk:<br />
<br />
https://svn.freepascal.org/svn/fpc/trunk<br />
<br />
To check it out, use subversion:<br />
<br />
mkdir fpc-z80<br />
cd fpc-z80<br />
svn co https://svn.freepascal.org/svn/fpc/trunk fpc<br />
<br />
== Requirements ==<br />
<br />
The assembler and linker from the SDCC package are required:<br />
<br />
http://sdcc.sourceforge.net/<br />
<br />
== Targets ==<br />
<br />
=== Embedded ===<br />
<br />
The compiler produces files in the IHX format (Intel HEX Format).<br />
<br />
=== ZX Spectrum ===<br />
<br />
The compiler produces ZX Spectrum tape files in the TZX file format. They are suitable for running in emulators. An open-source emulator that works is FBZX:<br />
<br />
https://www.rastersoft.com/programas/fbzx.html<br />
<br />
ROM images for the emulator are available here:<br />
<br />
http://www.chiark.greenend.org.uk/~cjwatson/code/spectrum-roms/<br />
<br />
and here:<br />
<br />
http://www.shadowmagic.org.uk/spectrum/roms.html<br />
<br />
They are copyrighted and are not free (as in freedom), but are legally available for use in emulators (not in real hardware), and are also repackaged and redistributed in Linux repositories such as [https://rpmfusion.org/ RPMFusion - nonfree].<br />
<br />
Another emulator that works is Fuse:<br />
<br />
http://fuse-emulator.sourceforge.net/fuse.php<br />
<br />
Producing TZX files requires a tool, called '''ihxutil''', which is written in Pascal and is available in the ''utils/ihxutil'' directory of the compiler.<br />
<br />
=== MSX-DOS ===<br />
<br />
The compiler produces flat COM files that can be run from the MSX-DOS environment. Please note that you need to take extreme care that you don't link in too much code especially if you want to also include a heap and a stack. The default size for the heap is 256 and for the stack 1024 and these can be changed using the ''$MEMORY'' directive.<br />
<br />
Generating the COM files requires the '''ihxutil''' utility which is written in Pascal and is available in the ''utils/ihxutil'' directory of the Free Pascal sources.<br />
<br />
== Building ==<br />
<br />
Here's the build script I use:<br />
<br />
#! /bin/sh<br />
<br />
set -e<br />
<br />
FPC_Z80_DIR=/home/nickysn/tralala/fpc-z80<br />
STARTPP=fpc<br />
BINUTILSPREFIX=<br />
<br />
CROSSOPT=-O-1<br />
export CROSSOPT<br />
OPT="-CX -XXs"<br />
if [ -n "$EXTRAOPT" ]<br />
then<br />
OPT+=" $EXTRAOPT"<br />
fi<br />
export OPT<br />
export CPU_TARGET=z80<br />
export OS_TARGET=zxspectrum<br />
export OS_SOURCE=`$STARTPP -iSO`<br />
export CPU_SOURCE=`$STARTPP -iSP`<br />
<br />
cd $FPC_Z80_DIR/fpc<br />
make -j `nproc` clean PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` all PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` crossinstall PP=$FPC_Z80_DIR/fpc/compiler/ppcrossz80 INSTALL_PREFIX=$FPC_Z80_DIR/zxspectrum-snapshot BINUTILSPREFIX=$BINUTILSPREFIX<br />
<br />
Note that, if you use the SDCC package from the official Fedora repositories, you might need to replace<br />
<br />
BINUTILSPREFIX=<br />
<br />
with<br />
<br />
BINUTILSPREFIX=sdcc-<br />
<br />
When compiling programs, you should always enable smartlinking by adding these two options to the compiler:<br />
<br />
-CX -XX<br />
<br />
== Status ==<br />
<br />
As of Apr 27, 2020, the code generator is stable enough to compile the full system unit. Standard output via write/writeln works now. As of May 17, 2020, optimization level 1 also works, so you can try compiling with -O1. Note that there aren't many Z80-specific optimizations implemented yet, but enabling optimization still has some small effect. Here's a simple program that works:<br />
<br />
program Hello;<br />
var<br />
b: byte;<br />
begin<br />
Write('FPC');<br />
for b := 0 to 255 do<br />
Write(HexStr(b, 2));<br />
end.<br />
<br />
Here's what this program produces in the FBZX emulator:<br />
<br />
[[File:ZX_Spectrum_hello_world_FBZX_emulator_screenshot.png]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Z80&diff=137002Z802020-06-06T17:27:08Z<p>PascalDragon: Initial documentation of MSX DOS target</p>
<hr />
<div>== Overview ==<br />
<br />
A Z80 port is currently under development in FPC trunk:<br />
<br />
https://svn.freepascal.org/svn/fpc/trunk<br />
<br />
To check it out, use subversion:<br />
<br />
mkdir fpc-z80<br />
cd fpc-z80<br />
svn co https://svn.freepascal.org/svn/fpc/trunk fpc<br />
<br />
== Requirements ==<br />
<br />
The assembler and linker from the SDCC package are required:<br />
<br />
http://sdcc.sourceforge.net/<br />
<br />
== Targets ==<br />
<br />
=== Embedded ===<br />
<br />
The compiler produces files in the IHX format (Intel HEX Format).<br />
<br />
=== ZX Spectrum ===<br />
<br />
The compiler produces ZX Spectrum tape files in the TZX file format. They are suitable for running in emulators. An open-source emulator that works is FBZX:<br />
<br />
https://www.rastersoft.com/programas/fbzx.html<br />
<br />
ROM images for the emulator are available here:<br />
<br />
http://www.chiark.greenend.org.uk/~cjwatson/code/spectrum-roms/<br />
<br />
and here:<br />
<br />
http://www.shadowmagic.org.uk/spectrum/roms.html<br />
<br />
They are copyrighted and are not free (as in freedom), but are legally available for use in emulators (not in real hardware), and are also repackaged and redistributed in Linux repositories such as [https://rpmfusion.org/ RPMFusion - nonfree].<br />
<br />
Another emulator that works is Fuse:<br />
<br />
http://fuse-emulator.sourceforge.net/fuse.php<br />
<br />
Producing TZX files requires a tool, called '''ihx2tzx''', which is written in Pascal and is available in the ''utils/ihx2tzx'' directory of the compiler.<br />
<br />
=== MSX-DOS ===<br />
<br />
The compiler produces flat COM files that can be run from the MSX-DOS environment. Please note that you need to take extreme care that you don't link in too much code especially if you want to also include a heap and a stack. The default size for the heap is 256 and for the stack 1024 and these can be changed using the ''$MEMORY'' directive.<br />
<br />
Generating the COM files requires the '''ihxutil''' utility which is written in Pascal and is available in the ''utils/ihxutil'' directory of the Free Pascal sources.<br />
<br />
== Building ==<br />
<br />
Here's the build script I use:<br />
<br />
#! /bin/sh<br />
<br />
set -e<br />
<br />
FPC_Z80_DIR=/home/nickysn/tralala/fpc-z80<br />
STARTPP=fpc<br />
BINUTILSPREFIX=<br />
<br />
CROSSOPT=-O-1<br />
export CROSSOPT<br />
OPT="-CX -XXs"<br />
if [ -n "$EXTRAOPT" ]<br />
then<br />
OPT+=" $EXTRAOPT"<br />
fi<br />
export OPT<br />
export CPU_TARGET=z80<br />
export OS_TARGET=zxspectrum<br />
export OS_SOURCE=`$STARTPP -iSO`<br />
export CPU_SOURCE=`$STARTPP -iSP`<br />
<br />
cd $FPC_Z80_DIR/fpc<br />
make -j `nproc` clean PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` all PP=$STARTPP BINUTILSPREFIX=$BINUTILSPREFIX<br />
make -j `nproc` crossinstall PP=$FPC_Z80_DIR/fpc/compiler/ppcrossz80 INSTALL_PREFIX=$FPC_Z80_DIR/zxspectrum-snapshot BINUTILSPREFIX=$BINUTILSPREFIX<br />
<br />
Note that, if you use the SDCC package from the official Fedora repositories, you might need to replace<br />
<br />
BINUTILSPREFIX=<br />
<br />
with<br />
<br />
BINUTILSPREFIX=sdcc-<br />
<br />
When compiling programs, you should always enable smartlinking by adding these two options to the compiler:<br />
<br />
-CX -XX<br />
<br />
== Status ==<br />
<br />
As of Apr 27, 2020, the code generator is stable enough to compile the full system unit. Standard output via write/writeln works now. As of May 17, 2020, optimization level 1 also works, so you can try compiling with -O1. Note that there aren't many Z80-specific optimizations implemented yet, but enabling optimization still has some small effect. Here's a simple program that works:<br />
<br />
program Hello;<br />
var<br />
b: byte;<br />
begin<br />
Write('FPC');<br />
for b := 0 to 255 do<br />
Write(HexStr(b, 2));<br />
end.<br />
<br />
Here's what this program produces in the FBZX emulator:<br />
<br />
[[File:ZX_Spectrum_hello_world_FBZX_emulator_screenshot.png]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=ZenGL&diff=136543ZenGL2020-05-21T10:52:43Z<p>PascalDragon: Added link to GitHub mirror</p>
<hr />
<div>{{ZenGL}}<br />
<br />
{{ZenGL Tutorial Index}}<br />
<br />
== Main ==<br />
ZenGL - cross-platform game development library, designed to provide necessary functionality for rendering 2D graphics, handling input, sound output, etc.<br />
<br />
'''Supported OS''': GNU/Linux, Windows, macOS, iOS, Android 2.1+<br><br />
'''Supported compilers''': FreePascal, Delphi<br><br />
'''Graphics API''': OpenGL, OpenGL ES 1.x, Direct3D 8/9<br><br />
'''Sound API''': OpenAL, DirectSound<br><br />
'''License''': [http://zengl.org/license.html zlib]<br />
<br />
== Links ==<br />
<br />
*[http://zengl.org/download.html Download ZenGL]<br><br />
*[https://github.com/andru-kun/zengl ZenGL Mirror on GitHub]<br />
*[http://zengl.org/extra.html Extra Downloads]<br />
*[http://zengl.org/ Homepage]<br><br />
*[http://zengl.org/wiki Wiki]<br><br />
*[http://zengl.org/forum Official forum]<br><br />
*[http://code.google.com/p/zengl/issues/list Bugtracker]<br />
*[https://github.com/thecocce/steamwrapper ZenGL on Steam]<br />
<br />
== Tutorial ==<br />
<br />
[[ZenGL Tutorial]]: This is a first tutorial for ZenGL: download, installation, source paths, compilation (statically or with so/dll/dylib) (Windows dll), and the First program 'Initialization' that comes with ZenGL.<br />
<br />
[[ZenGL Tutorial 2]]: This is the second tutorial on how to create a font and draw text in the window.<br />
<br />
== Features ==<br />
<br />
* '''Main'''<br />
o can be used as so/dll/dylib or statically compiled with your application <br />
o rendering to own or any other prepared window<br />
o logging<br />
o resource loading from files, memory and '''zip''' archives<br />
o multithreaded resource loading<br />
o easy way to add support for new resource format<br />
* '''Configuration of'''<br />
o antialiasing, screen resolution, refresh rate and vertical synchronization<br />
o aspect correction<br />
o title, position and size of window<br />
o cursor visibility in window space<br />
* '''Input'''<br />
o handling of keyboard, mouse and joystick input<br />
o handling of Unicode text input<br />
o possibility to restrict the input to the Latin alphabet<br />
* '''Textures'''<br />
o supports '''tga''', '''png''', '''jpg''' and '''pvr'''<br />
o correct work with NPOT textures<br />
o control the filter parameters<br />
o masking<br />
o ''render targets'' for rendering into texture<br />
* '''Text'''<br />
o textured Unicode font<br />
o rendering UTF-8 text<br />
o rendering text with alignment and other options like size, color and count of symbols<br />
* '''2D subsystem'''<br />
o ''batch render'' for high-speed rendering<br />
o rendering different primitives<br />
o sprite engine<br />
o rendering static and animated sprites and tiles<br />
o rendering distortion grid<br />
o rendering sprites with new texture coordinates (with the pixel dimension and the usual 0..1)<br />
o control the blend mode and color mix mode<br />
o control the color and alpha of vertices of sprites and primitives<br />
o additional sprite transformations (flipping, zooming, vertices offset)<br />
o fast clipping of invisible sprites<br />
o 2D camera with ability to zoom and rotate the scene<br />
* '''Sound'''<br />
o works through OpenAL or DirectSound; depends on configuration or OS<br />
o correct work without soundcard<br />
o supports '''wav''' and '''ogg''' as sound sample formats<br />
o playing audio files in separate thread<br />
o control volume and playback speed<br />
o moving sound sources in 3D space<br />
* '''Video'''<br />
o decoding video frames into texture<br />
o supports '''theora''' codec in '''ogv''' container<br />
* '''Math'''<br />
o basic set of additional math functions<br />
o triangulation functions<br />
o basic set of collision functions<br />
* '''Additional'''<br />
o reading and writing INI files<br />
o functions for working with files and memory<br />
<br />
[[Category:Components]]<br />
[[Category:Graphics]]<br />
[[Category:Audio]]<br />
[[Category:Multimedia]]<br />
[[Category:Video]]<br />
[[Category:Game Development]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Platform_list&diff=135642Platform list2020-04-28T19:18:13Z<p>PascalDragon: Z80 has been merged</p>
<hr />
<div>{{Platform list}}<br />
<br />
== Supported architectures ==<br />
SVN trunk contains support at various levels of completeness for the following architectures:<br />
<br />
* i386<br />
* AMD64 (x86-64)<br />
* i8086<br />
* [[ARM]]<br />
* AArch64<br />
* [[PowerPC]]<br />
* [[PowerPC64 Port|PowerPC64]]<br />
* [[m68k]]<br />
* SPARC<br />
* SPARC64<br />
* MIPS<br />
* [[AVR]]<br />
* RISC-V<br />
* [[Z80]]<br />
* JVM bytecode<br />
* LLVM IR<br />
<br />
== Other architectures and their status ==<br />
* Webassembly: separate branch, initial implementation only<br />
<br />
== Former ports which were removed ==<br />
* iA64/Itanium:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
** Itanium has been officially discontinued as of January 30th, 2019<br />
* Alpha:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
<br />
== Supported targets for i386 ==<br />
* Win32 for i386<br />
* Linux for i386<br />
* [[Target Darwin]] (macOS) for i386 (2.1.x and later)<br />
* [[FreeBSD]]/ELF for i386<br />
* [[Android]] for i386<br />
* OpenBSD for i386 (under development, currently maintainerless)<br />
* [[Target OS2|OS/2]] / eComStation<br />
* [[GO32V2]] DOS extender<br />
* SunOS/ELF for i386 (under development)<br />
* [[BeOS port]] for i386 (under development)<br />
* NetBSD for i386 (under development, currently maintainerless)<br />
* [[Netware]] for i386 (clib and libc)<br />
* WDOSX DOS extender<br />
* OS/2 via EMX (equal to OS/2 target in 1.0.x and earlier; RTL based on EMX runtime library allows building applications running under DOS with EMX extender; currently not completely up to date)<br />
* Watcom compatible DOS extenders<br />
* [http://sourceforge.net/projects/befpc/ BeOS/Zeta/Haiku] for i386<br />
* [[Target NativeNT]] for i386 (under development)<br />
* [[AROS]] for i386<br />
<br />
== Supported targets for [[AMD64]] ([[x86-64]]) == <br />
* [[Linux for AMD64]]<br />
* [[Win64 for AMD64]]<br />
* [[Target Darwin]] (macOS) (2.3.x and later)<br />
* FreeBSD for AMD64 (2.4.2 and later)<br />
<br />
== Supported targets for [[i8086]] == <br />
* [[DOS]]<br />
* Windows 16bit<br />
* Embedded<br />
<br />
== Supported targets for ARM ==<br />
* [[Linux for ARM]]<br />
* [[Android]] for ARM<br />
* [[iPhone/iPod_development|Target Darwin]] (iOS) (2.3.x and later)<br />
* [[WinCE port|Windows CE/Windows Mobile/Pocket PC]]<br />
* [[GameBoy Advance]] (under development)<br />
* [[Nintendo DS]] (under development)<br />
* [[PalmOS port]] (under development)<br />
* [[SymbianOS]] (development abandoned)<br />
* [[Native ARM Systems]] (not cross-development)<br />
* [[Embedded]]<br />
<br />
== Supported targets for AArch64 ==<br />
* Linux for AArch64<br />
* [[Target Darwin]] (iOS 64bit)<br />
* Windows for ARM64<br />
<br />
== Supported targets for PowerPC ==<br />
* Linux for PowerPC<br />
* [[Target Darwin|Darwin]] (Mac OS X)<br />
* NetBSD (core done, but not kept up to speed)<br />
* [[Target MacOS|MacOS]] (classic)<br />
* [[MorphOS]]<br />
* [[AmigaOS|AmigaOS 4.x]] (maintainerless, but kept in a buildable state)<br />
* [[Wii|Nintendo Wii]] (under development)<br />
<br />
== Supported targets for PowerPC64 ==<br />
* Linux (2.1.x and later)<br />
* [[Target Darwin]] (Mac OS X) (2.3.x and later)<br />
<br />
== Supported targets for m68k ==<br />
* [[Amiga]]<br />
* [[Portal:Linux|Linux]] for m68k<br />
* NetBSD (ELF only)<br />
* [[Atari|Atari TOS]] (compiler itself works, but it's still in early stage)<br />
* [[Target MacOS|MacOS]] (classic, planned)<br />
* [[PalmOS port|Palm OS / Garnet OS]] (planned)<br />
* [[Embedded]] (planned)<br />
<br />
See page [[m68k]] for details.<br />
<br />
== Supported targets for SPARC ==<br />
* [[SunOS/ELF]] for SPARC (in maintenance mode)<br />
* Linux for SPARC<br />
<br />
== Supported targets for SPARC64 ==<br />
* Linux for SPARC64<br />
<br />
== Supported targets for MIPS ==<br />
* Linux for MIPS<br />
<br />
== Supported targets for PIC ==<br />
* Embedded<br />
<br />
See [[TARGET Embedded Mipsel|MIPSEL]] page for details<br />
<br />
== Supported targets for AVR ==<br />
* Embedded<br />
<br />
See [[AVR]] page for details.<br />
<br />
== Supported targets for RISC-V ==<br />
* Linux<br />
* Embedded<br />
<br />
Both 32- and 64-bit are supported.<br />
<br />
== Supported targets for Z80 ==<br />
* SpectrumZX<br />
* Embedded<br />
<br />
== Unofficial 3rd party ports ==<br />
<br />
* [[GP2X]] (under development)<br />
<br />
* [[UEFI]] Unified Extensible Firmware Interface (under early development)<br />
<br />
* [[ZSeries]] IBM System/370, S/390 and zSeries mainframes (under development as "i370")<br />
<br />
== Unlikely to be ported ==<br />
<br />
* [[Sanos]] Win32-compatible console-mode operating system<br />
<br />
* MUSIC/SP OS-compatible IBM mainframe operating system, using EBCDIC. [[Qemu and other emulators#MUSIC/SP using Sim/390 or Hercules]]<br />
<br />
== Resources for porting to new platforms... ==<br />
... and keeping existing ones up to date.<br />
* [[FPC HowToDo]] - new additions requiring attention of platform maintainers<br />
* [[System unit structure]] - (work in progress - only skeleton finished) description of System unit internals<br />
<br />
== Cross compilation ==<br />
Information about compilation for a different platform as the one running the compiler may be found in [[Cross compiling]].<br />
<br />
[[Category: Operating Systems and Platforms]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Platform_list&diff=135641Platform list2020-04-28T19:16:53Z<p>PascalDragon: RISC-V has been reintegrated some time ago</p>
<hr />
<div>{{Platform list}}<br />
<br />
== Supported architectures ==<br />
SVN trunk contains support at various levels of completeness for the following architectures:<br />
<br />
* i386<br />
* AMD64 (x86-64)<br />
* i8086<br />
* [[ARM]]<br />
* AArch64<br />
* [[PowerPC]]<br />
* [[PowerPC64 Port|PowerPC64]]<br />
* [[m68k]]<br />
* SPARC<br />
* SPARC64<br />
* MIPS<br />
* [[AVR]]<br />
* RISC-V<br />
* JVM bytecode<br />
* LLVM IR<br />
<br />
== Other architectures and their status ==<br />
* [[Z80]]: separate branch, initial implementation only<br />
* Webassembly: separate branch, initial implementation only<br />
<br />
== Former ports which were removed ==<br />
* iA64/Itanium:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
** Itanium has been officially discontinued as of January 30th, 2019<br />
* Alpha:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
<br />
== Supported targets for i386 ==<br />
* Win32 for i386<br />
* Linux for i386<br />
* [[Target Darwin]] (macOS) for i386 (2.1.x and later)<br />
* [[FreeBSD]]/ELF for i386<br />
* [[Android]] for i386<br />
* OpenBSD for i386 (under development, currently maintainerless)<br />
* [[Target OS2|OS/2]] / eComStation<br />
* [[GO32V2]] DOS extender<br />
* SunOS/ELF for i386 (under development)<br />
* [[BeOS port]] for i386 (under development)<br />
* NetBSD for i386 (under development, currently maintainerless)<br />
* [[Netware]] for i386 (clib and libc)<br />
* WDOSX DOS extender<br />
* OS/2 via EMX (equal to OS/2 target in 1.0.x and earlier; RTL based on EMX runtime library allows building applications running under DOS with EMX extender; currently not completely up to date)<br />
* Watcom compatible DOS extenders<br />
* [http://sourceforge.net/projects/befpc/ BeOS/Zeta/Haiku] for i386<br />
* [[Target NativeNT]] for i386 (under development)<br />
* [[AROS]] for i386<br />
<br />
== Supported targets for [[AMD64]] ([[x86-64]]) == <br />
* [[Linux for AMD64]]<br />
* [[Win64 for AMD64]]<br />
* [[Target Darwin]] (macOS) (2.3.x and later)<br />
* FreeBSD for AMD64 (2.4.2 and later)<br />
<br />
== Supported targets for [[i8086]] == <br />
* [[DOS]]<br />
* Windows 16bit<br />
* Embedded<br />
<br />
== Supported targets for ARM ==<br />
* [[Linux for ARM]]<br />
* [[Android]] for ARM<br />
* [[iPhone/iPod_development|Target Darwin]] (iOS) (2.3.x and later)<br />
* [[WinCE port|Windows CE/Windows Mobile/Pocket PC]]<br />
* [[GameBoy Advance]] (under development)<br />
* [[Nintendo DS]] (under development)<br />
* [[PalmOS port]] (under development)<br />
* [[SymbianOS]] (development abandoned)<br />
* [[Native ARM Systems]] (not cross-development)<br />
* [[Embedded]]<br />
<br />
== Supported targets for AArch64 ==<br />
* Linux for AArch64<br />
* [[Target Darwin]] (iOS 64bit)<br />
* Windows for ARM64<br />
<br />
== Supported targets for PowerPC ==<br />
* Linux for PowerPC<br />
* [[Target Darwin|Darwin]] (Mac OS X)<br />
* NetBSD (core done, but not kept up to speed)<br />
* [[Target MacOS|MacOS]] (classic)<br />
* [[MorphOS]]<br />
* [[AmigaOS|AmigaOS 4.x]] (maintainerless, but kept in a buildable state)<br />
* [[Wii|Nintendo Wii]] (under development)<br />
<br />
== Supported targets for PowerPC64 ==<br />
* Linux (2.1.x and later)<br />
* [[Target Darwin]] (Mac OS X) (2.3.x and later)<br />
<br />
== Supported targets for m68k ==<br />
* [[Amiga]]<br />
* [[Portal:Linux|Linux]] for m68k<br />
* NetBSD (ELF only)<br />
* [[Atari|Atari TOS]] (compiler itself works, but it's still in early stage)<br />
* [[Target MacOS|MacOS]] (classic, planned)<br />
* [[PalmOS port|Palm OS / Garnet OS]] (planned)<br />
* [[Embedded]] (planned)<br />
<br />
See page [[m68k]] for details.<br />
<br />
== Supported targets for SPARC ==<br />
* [[SunOS/ELF]] for SPARC (in maintenance mode)<br />
* Linux for SPARC<br />
<br />
== Supported targets for SPARC64 ==<br />
* Linux for SPARC64<br />
<br />
== Supported targets for MIPS ==<br />
* Linux for MIPS<br />
<br />
== Supported targets for PIC ==<br />
* Embedded<br />
<br />
See [[TARGET Embedded Mipsel|MIPSEL]] page for details<br />
<br />
== Supported targets for AVR ==<br />
* Embedded<br />
<br />
See [[AVR]] page for details.<br />
<br />
== Supported targets for RISC-V ==<br />
* Linux<br />
* Embedded<br />
<br />
Both 32- and 64-bit are supported.<br />
<br />
== Unofficial 3rd party ports ==<br />
<br />
* [[GP2X]] (under development)<br />
<br />
* [[UEFI]] Unified Extensible Firmware Interface (under early development)<br />
<br />
* [[ZSeries]] IBM System/370, S/390 and zSeries mainframes (under development as "i370")<br />
<br />
== Unlikely to be ported ==<br />
<br />
* [[Sanos]] Win32-compatible console-mode operating system<br />
<br />
* MUSIC/SP OS-compatible IBM mainframe operating system, using EBCDIC. [[Qemu and other emulators#MUSIC/SP using Sim/390 or Hercules]]<br />
<br />
== Resources for porting to new platforms... ==<br />
... and keeping existing ones up to date.<br />
* [[FPC HowToDo]] - new additions requiring attention of platform maintainers<br />
* [[System unit structure]] - (work in progress - only skeleton finished) description of System unit internals<br />
<br />
== Cross compilation ==<br />
Information about compilation for a different platform as the one running the compiler may be found in [[Cross compiling]].<br />
<br />
[[Category: Operating Systems and Platforms]]</div>PascalDragonhttps://wiki.freepascal.org/index.php?title=Platform_list&diff=135640Platform list2020-04-28T19:14:57Z<p>PascalDragon: mentioned support for Windows on ARM64</p>
<hr />
<div>{{Platform list}}<br />
<br />
== Supported architectures ==<br />
SVN trunk contains support at various levels of completeness for the following architectures:<br />
<br />
* i386<br />
* AMD64 (x86-64)<br />
* i8086<br />
* [[ARM]]<br />
* AArch64<br />
* [[PowerPC]]<br />
* [[PowerPC64 Port|PowerPC64]]<br />
* [[m68k]]<br />
* SPARC<br />
* SPARC64<br />
* MIPS<br />
* [[AVR]]<br />
* JVM bytecode<br />
* LLVM IR<br />
<br />
== Other architectures and their status ==<br />
* RISC-V: separate branch<br />
* [[Z80]]: separate branch, initial implementation only<br />
* Webassembly: separate branch, initial implementation only<br />
<br />
== Former ports which were removed ==<br />
* iA64/Itanium:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
** Itanium has been officially discontinued as of January 30th, 2019<br />
* Alpha:<br />
** Non-compiling compiler, only some basic units for the compiler were implemented<br />
<br />
== Supported targets for i386 ==<br />
* Win32 for i386<br />
* Linux for i386<br />
* [[Target Darwin]] (macOS) for i386 (2.1.x and later)<br />
* [[FreeBSD]]/ELF for i386<br />
* [[Android]] for i386<br />
* OpenBSD for i386 (under development, currently maintainerless)<br />
* [[Target OS2|OS/2]] / eComStation<br />
* [[GO32V2]] DOS extender<br />
* SunOS/ELF for i386 (under development)<br />
* [[BeOS port]] for i386 (under development)<br />
* NetBSD for i386 (under development, currently maintainerless)<br />
* [[Netware]] for i386 (clib and libc)<br />
* WDOSX DOS extender<br />
* OS/2 via EMX (equal to OS/2 target in 1.0.x and earlier; RTL based on EMX runtime library allows building applications running under DOS with EMX extender; currently not completely up to date)<br />
* Watcom compatible DOS extenders<br />
* [http://sourceforge.net/projects/befpc/ BeOS/Zeta/Haiku] for i386<br />
* [[Target NativeNT]] for i386 (under development)<br />
* [[AROS]] for i386<br />
<br />
== Supported targets for [[AMD64]] ([[x86-64]]) == <br />
* [[Linux for AMD64]]<br />
* [[Win64 for AMD64]]<br />
* [[Target Darwin]] (macOS) (2.3.x and later)<br />
* FreeBSD for AMD64 (2.4.2 and later)<br />
<br />
== Supported targets for [[i8086]] == <br />
* [[DOS]]<br />
* Windows 16bit<br />
* Embedded<br />
<br />
== Supported targets for ARM ==<br />
* [[Linux for ARM]]<br />
* [[Android]] for ARM<br />
* [[iPhone/iPod_development|Target Darwin]] (iOS) (2.3.x and later)<br />
* [[WinCE port|Windows CE/Windows Mobile/Pocket PC]]<br />
* [[GameBoy Advance]] (under development)<br />
* [[Nintendo DS]] (under development)<br />
* [[PalmOS port]] (under development)<br />
* [[SymbianOS]] (development abandoned)<br />
* [[Native ARM Systems]] (not cross-development)<br />
* [[Embedded]]<br />
<br />
== Supported targets for AArch64 ==<br />
* Linux for AArch64<br />
* [[Target Darwin]] (iOS 64bit)<br />
* Windows for ARM64<br />
<br />
== Supported targets for PowerPC ==<br />
* Linux for PowerPC<br />
* [[Target Darwin|Darwin]] (Mac OS X)<br />
* NetBSD (core done, but not kept up to speed)<br />
* [[Target MacOS|MacOS]] (classic)<br />
* [[MorphOS]]<br />
* [[AmigaOS|AmigaOS 4.x]] (maintainerless, but kept in a buildable state)<br />
* [[Wii|Nintendo Wii]] (under development)<br />
<br />
== Supported targets for PowerPC64 ==<br />
* Linux (2.1.x and later)<br />
* [[Target Darwin]] (Mac OS X) (2.3.x and later)<br />
<br />
== Supported targets for m68k ==<br />
* [[Amiga]]<br />
* [[Portal:Linux|Linux]] for m68k<br />
* NetBSD (ELF only)<br />
* [[Atari|Atari TOS]] (compiler itself works, but it's still in early stage)<br />
* [[Target MacOS|MacOS]] (classic, planned)<br />
* [[PalmOS port|Palm OS / Garnet OS]] (planned)<br />
* [[Embedded]] (planned)<br />
<br />
See page [[m68k]] for details.<br />
<br />
== Supported targets for SPARC ==<br />
* [[SunOS/ELF]] for SPARC (in maintenance mode)<br />
* Linux for SPARC<br />
<br />
== Supported targets for SPARC64 ==<br />
* Linux for SPARC64<br />
<br />
== Supported targets for MIPS ==<br />
* Linux for MIPS<br />
<br />
== Supported targets for PIC ==<br />
* Embedded<br />
<br />
See [[TARGET Embedded Mipsel|MIPSEL]] page for details<br />
<br />
== Supported targets for AVR ==<br />
* Embedded<br />
<br />
See [[AVR]] page for details.<br />
<br />
== Unofficial 3rd party ports ==<br />
<br />
* [[GP2X]] (under development)<br />
<br />
* [[UEFI]] Unified Extensible Firmware Interface (under early development)<br />
<br />
* [[ZSeries]] IBM System/370, S/390 and zSeries mainframes (under development as "i370")<br />
<br />
== Unlikely to be ported ==<br />
<br />
* [[Sanos]] Win32-compatible console-mode operating system<br />
<br />
* MUSIC/SP OS-compatible IBM mainframe operating system, using EBCDIC. [[Qemu and other emulators#MUSIC/SP using Sim/390 or Hercules]]<br />
<br />
== Resources for porting to new platforms... ==<br />
... and keeping existing ones up to date.<br />
* [[FPC HowToDo]] - new additions requiring attention of platform maintainers<br />
* [[System unit structure]] - (work in progress - only skeleton finished) description of System unit internals<br />
<br />
== Cross compilation ==<br />
Information about compilation for a different platform as the one running the compiler may be found in [[Cross compiling]].<br />
<br />
[[Category: Operating Systems and Platforms]]</div>PascalDragon