View Issue Details

IDProjectCategoryView StatusLast Update
0033862FPCDocumentationpublic2018-06-19 09:10
ReporterMartin FriebeAssigned ToMichael Van Canneyt 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platform64bit IntelOSwin 10OS Version10
Product Version3.0.4Product Build 
Target Version3.2.0Fixed in Version3.1.1 
Summary0033862: incorrect inherited call silently ignored / no code / no error
DescriptionIf you have a call
  inherited;
without name (so calling the procedure of the same name in the base class), but no function exists in any base class (or there is one but it is not visible) then the line does neither generate code nor give an error.

I would expect an error, since the code attempts something that is not possible.

Specifying the name, will produce an error.
  inherited Bar;
project1.lpr(14,13) Error: identifier idents no member "Bar"
Steps To ReproduceSee code in "Additional Info" below.

The code in the program attempts to call the private function "Bar" in Unit1.
Since TFoo.Bar is private, it is not visible. So it can not be called.

The line "inherited" will be ignored, it should give an error.

The same happens, if TFoo has no procedure Bar (rename it to Foo.NewBar), again inherited is silently ignored.
Additional Informationprogram Project1;
{$mode objfpc}{$H+}
uses Classes, unit1;
type
  TFooDerived = class(TFoo)
  public
    procedure Bar;
  end;

var a: TFooDerived;

procedure TFooDerived.Bar;
begin
  inherited;
  writeln(2);
end;

begin
  a := TFooDerived.Create;
  a.Bar;
  readln;
end.


unit Unit1;
{$mode objfpc}{$H+}
interface
uses
  Classes, SysUtils;

type
  TFoo = class
  private
    procedure Bar;
  end;

implementation
procedure TFoo.Bar;
begin
  writeln(1);
end;


end.
TagsNo tags attached.
Fixed in Revision1487
FPCOldBugId0
FPCTarget
Attached Files

Activities

Ondrej Pokorny

2018-06-15 07:43

developer   ~0108912

This is a feature and Delphi behaves the same. Error definitely doesn't belong here, maybe only a compiler hint/note that the inherited call is ignored.

(Btw. already now you can see that the inherited call is ignored because the line doesn't have a debugger dot when debugging.)

Martin Friebe

2018-06-15 10:20

manager   ~0108913

It is not in the fpc docs: https://www.freepascal.org/docs-html/ref/refsu32.html

Is it in the Delphi docs? If not, Delphi has bugs too.

Ondrej Pokorny

2018-06-15 10:43

developer   ~0108914

> It is not in the fpc docs: https://www.freepascal.org/docs-html/ref/refsu32.html [^]

You forgot the scenario that the docs could be incomplete.

> Is it in the Delphi docs? If not, Delphi has bugs too.

It looks like you just discovered a feature that has been in Delphi since forever :)

Delphi issue reports are in Embarcadero Quality Central. And yes, there is exactly this issue listed and resolved as "Works as Expected": https://quality.embarcadero.com/browse/RSP-18124

Quote from Embarcadero developers:
The two forms of the "inherited" are very similar but not identical. The first [inherited Bar;] involves specifying the method name and parameter list. This form is a direct call of the method from the parent class. If the parent class does not have such a method then, as you find, an error is generated.

The second form [inherited;] where no method name or parameter list is specified represents a special use of "inherited". In such case, a call to an inherited method may occur if it exists or not if it doesn't. Such a reference is limited to methods with the same name and parameter list in the parent class or in the case message handlers, methods handling the same message ID in the parent class.

Unlike the former case, if the parent class has no such method, no error is generated for the statement, but also no code is generated. This behavior simplifies automatic source generation as happens in the IDE's code editor when different project types are created.
(Quote end)

Ondrej Pokorny

2018-06-15 10:53

developer   ~0108915

Well I found an issue report even in FPC bugtracker: 0003955

Sven Barth

2018-06-15 15:55

manager   ~0108919

I've changed this to category Documentation, so that it will at least be documented in ours :)

Michael Van Canneyt

2018-06-19 09:10

administrator   ~0108963

Adapted the documentation.

Issue History

Date Modified Username Field Change
2018-06-15 00:56 Martin Friebe New Issue
2018-06-15 07:43 Ondrej Pokorny Note Added: 0108912
2018-06-15 10:20 Martin Friebe Note Added: 0108913
2018-06-15 10:43 Ondrej Pokorny Note Added: 0108914
2018-06-15 10:53 Ondrej Pokorny Note Added: 0108915
2018-06-15 15:54 Sven Barth Category Compiler => Documentation
2018-06-15 15:55 Sven Barth Note Added: 0108919
2018-06-15 15:55 Sven Barth Assigned To => Michael Van Canneyt
2018-06-15 15:55 Sven Barth Status new => assigned
2018-06-19 09:10 Michael Van Canneyt Fixed in Revision => 1487
2018-06-19 09:10 Michael Van Canneyt Note Added: 0108963
2018-06-19 09:10 Michael Van Canneyt Status assigned => resolved
2018-06-19 09:10 Michael Van Canneyt Fixed in Version => 3.1.1
2018-06-19 09:10 Michael Van Canneyt Resolution open => fixed
2018-06-19 09:10 Michael Van Canneyt Target Version => 3.2.0