View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035790||FPC||Compiler||public||2019-07-02 22:22||2019-07-12 14:25|
|Reporter||rd0x||Assigned To||Sven Barth|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Status||closed||Resolution||no change required|
|Product Version||Product Build|
|Target Version||Fixed in Version|
|Summary||0035790: Overload keyword in implementation part does not compile in Delphi while it does in FPC|
|Description||If you add overload keyword to functions in interface section AND also add overload into implementation section, compiling fails in Delphi Rio with "Error: E1030 Invalid compiler directive: 'OVERLOAD'" while FPC in Delphi mode compiles it.|
|Additional Information||Free Pascal Compiler version 3.2.0-beta [2019/07/01] for i386 and x64|
|Tags||No tags attached.|
|Fixed in Revision|
Am I right in thinking that Delphi doesn't allow "overload" to appear at all in the implementation section (I can't personally test this)? That is... it can only appear in the interface section.
If so, then this is a relatively easy fix, I think.
Regardless, before I try anything, can you test the following to confirm successful compilation or not under Delphi Rio?
- A function doesn't have 'overload' in the interface section, but does in the implementation section.
- A function has 'overload' in the main program/library source file.
Sorry, forgot to mention that it works for "normal functions" but fails for overloading functions inside a Class.
See also http://codeverge.com/embarcadero.delphi.general/e1030-invalid-compiler-directive-o/1041769
If regular functions work but object methods fail, this looks like a bug in Delphi at first glance.
My personal instinct is to wait to see what Embarcadero says, if anything. True, Delphi mode should be fully compatible, but should we also mimic its bugs?
I don't think its a bug as the thread is about D2007 and Delphi Rio still shows the same behavior, so I guess it has a reason?
Or nobody reported to Embarcadero...
||It happens. I've found bugs in projects that have existed for 8+ years, but haven't been reported previously because people haven't used the feature in a particular way or erroneously assumed "it's not a bug, it's a feature".|
||So going by the response in that Delphi topic, should it be changed so 'overload' cannot be in the implementation section? It seems odd to treat methods and functions differently in this instance.|
The thing is for classes (or records) *no* directives can be used on the method *definition*. Directives can only be used at a method *declaration* (a class can after all be declared in the implementation section). Global routines always behaved a bit differently here: For example you can have a "external XXX name YYY" that only exists at the routine's definiton in the implementation section, but not at it's declaration in the interface section (in fact if you use it at the implementation section you can *only* use it in the implementation section; or the other way round: if you use it in the interface section for the declaration, there must not be a definition in the implementation section).
For routine declarations and definitions it makes sense to allow them in the implementation section, cause routines might only exist there (or some overloads might only exist there). It was probably easier to simply allow it for all global routine declarations and definitions and to ignore it on routine definitions that have a declaration.
E.g. the following is valid as well:
=== code begin ===
procedure Bar(aStr: String); overload; forward;
procedure Bar(aInt: Integer); overload;
procedure Bar(aStr: String);
=== code end ===
The "overload" directive *must* appear at the forward declaration of Bar, but it *can* appear on the definition of Bar further down.
Also the rule of thumb for mode Delphi is that Delphi code should compile in FPC, but not that code written in mode Delphi must compile in Delphi (e.g. FPC's mode Delphi also allows global generic routines which Delphi does not support).
||So should this be closed and marked as 'no change required', Sven?|
@ J. Gareth Moreton
I'd say so
||Closed - see notes above.|
|2019-07-02 22:22||rd0x||New Issue|
|2019-07-02 22:30||J. Gareth Moreton||Note Added: 0117034|
|2019-07-02 22:30||J. Gareth Moreton||Note Edited: 0117034||View Revisions|
|2019-07-02 22:32||J. Gareth Moreton||Note Added: 0117035|
|2019-07-02 22:38||rd0x||Note Added: 0117036|
|2019-07-02 22:43||J. Gareth Moreton||Note Added: 0117038|
|2019-07-02 22:46||rd0x||Note Added: 0117039|
|2019-07-03 00:58||J. Gareth Moreton||Note Added: 0117042|
|2019-07-03 02:26||J. Gareth Moreton||Note Added: 0117043|
|2019-07-04 00:08||Sven Barth||Note Added: 0117052|
|2019-07-04 00:13||J. Gareth Moreton||Note Added: 0117053|
|2019-07-12 13:36||rd0x||Note Added: 0117216|
|2019-07-12 14:25||J. Gareth Moreton||Assigned To||=> Sven Barth|
|2019-07-12 14:25||J. Gareth Moreton||Status||new => closed|
|2019-07-12 14:25||J. Gareth Moreton||Resolution||open => no change required|
|2019-07-12 14:25||J. Gareth Moreton||FPCTarget||=> -|
|2019-07-12 14:25||J. Gareth Moreton||Note Added: 0117219|