Typisierte lokale Konstante in Generic-Unterklasse - Compiler-Bug?

[Der schöne Günther]

Delphi XE5 Enterprise, Update 1. Ich bin verwirrt. Man nehme folgende zwei Units und sorge dafür, dass auf einer TChildClass -Instanz die Methode doStuff() aufgerufen wird.

Soweit das $DEFINE CAUSE_URW_ERROR nicht auskommentiert wird, kann der Compiler die Unit ChildClass nicht kompilieren und meldet:

• "[dcc64 Fataler Fehler] ChildClass.pas(10): F2084 Interner Fehler: URW1154"
• "[dcc32 Fataler Fehler] ChildClass.pas(10): F2084 Interner Fehler: URW1154"

Andere Compiler-Backends habe ich nicht ausprobiert.

Delphi-Quellcode:

unit BaseClass;

interface
   type

      TBaseClass<T: class> = class abstract
         protected var
            someField: Boolean;
         public
            procedure doStuff(); virtual; final;
      end;

implementation

// {$DEFINE CAUSE_URW_ERROR}

// Causes fatal "Internal Error: URW1154" on Unit ChildClass.pas
// using dcc32 or dcc64

// Used version: "Embarcadero® Delphi® XE5 Version 19.0.13856.4978"
// meaning "RAD Studio XE5 Enterprise, Update 1"

procedure TBaseClass<T>.doStuff();
const
   {$IFDEF CAUSE_URW_ERROR}
      someConstant: Boolean = True;
   {$ELSE}
      someConstant = True;
   {$ENDIF}
   // Could as well be defined in the class header
   // The only thing that matters is that the constant has to be typed,
   // the superclass has to make use of generics and the subclass has to be
   // in another unit. That's all that matters.
begin
   someField := someConstant;
end;

end.

Delphi-Quellcode:

unit ChildClass;

interface uses BaseClass;

   type TChildClass = class(TBaseClass<TObject>);

implementation
end.

Wie man sieht läuft alles bestens, wenn die Konstante nicht explizit auf Boolean typisiert ist. Ich habe allerdings keine Ahnung, warum.

In der Fixliste für XE5 taucht komischerweise "F2084 Internal Error: URW1154" auf, der entsprechende QC-Report ist als "Resolved in Build: : XE5" markiert.

Mehr finde ich im Internet nicht. Was soll ich nun tun? Könnt Ihr das reproduzieren? Wie verhalten sich andere Compiler (OSX, iOS, Android)? Kann ich das so (wieder) im QC melden?

[jaenicke]

Ja, das ist reproduzierbar. Der Fehler tritt allerdings nur unter einigen Bedingungen auf, die du wohl auch schon bemerkt hast. Bei Android wird statt des internen Fehlers eine gute Fehlermeldung ausgespruckt, man merkt, dass dort der Compiler weiter entwickelt ist.

Ich kann dazu gerne einen entsprechenden QC Eintrag erstellen.

[Der schöne Günther]

Ich habe Harrys http://www.delphipraxis.net/177511-d...-tutorial.html leider immer noch nicht durchgelesen, deswegen bin ich da nicht sicher drin. Wäre nett wenn du das bei Zeiten übernehmen könntest

Ich habe die BaseClass-Unit noch einmal leicht mit Kommentaren geschmückt.

Aber jetzt bin ich mal interessiert: Was sagt der Android-Compiler denn? Explizit, das irgendetwas nicht gewollt oder "as designed" ist?

[jaenicke]

Den Report findest du hier:
http://qc.embarcadero.com/wc/qcmain.aspx?d=121517

Zitat von Der schöne Günther:

Ich habe Harrys http://www.delphipraxis.net/177511-d...-tutorial.html leider immer noch nicht durchgelesen, deswegen bin ich da nicht sicher drin.

Das ist nicht aktuell. Das aktuelle Tool funktioniert Wizard-basiert und bietet deutlich mehr Funktionen. Ein Screenshot des Reports in diesem Tool:

Zitat von Der schöne Günther:

Ich habe die BaseClass-Unit noch einmal leicht mit Kommentaren geschmückt.

Ich habe sie auf das allernotwendigste gekürzt in dem Anhang des Reports.

Zitat von Der schöne Günther:

Aber jetzt bin ich mal interessiert: Was sagt der Android-Compiler denn? Explizit, das irgendetwas nicht gewollt oder "as designed" ist?

Zitat:

[DCC Fehler] ChildClass.pas(16): E2581 Backend-Fehler: invalid linkage type for global declaration
%6* @_ZZN9Baseclass13TBaseClass__1IN6System12DelphiObj ectINS1_7TObjectEEEE7doStuffEvE12someConstant
Broken module found, compilation terminated.

Sprich es kommt eine gute Fehlermeldung, an der man erkennen kann wo der Fehler entsteht. Deshalb schalte ich auch (sofern in dem Projekt möglich) bei internen Fehlern auf Android um und schaue was da passiert.

[Der schöne Günther]

Ja, auf Windows ist er einfach nur ans Ende der Unit gesprungen und die letzte Zeile rot angemalt. Da war die Fehlersuche schon etwas schwerer, vor allem wenn es nicht so ein Minimalgerüst wie jetzt

[jaenicke]

Da lösche ich meistens einfach alles aus dem Projekt bis nur noch der Fehler übrig bleibt sozusagen, wenn der Android Weg nicht geht.

Übrigens wurde der QC Eintrag mittlerweile geöffnet, als "Critical / Show Stopper" eingestuft und ins interne Tracking übernommen.

[Der schöne Günther]

Schön, das ging ja flott

Was mir erst durch deinen QC-Titel aufgefallen ist: Das ist ja tatsächlich nur bei Boolean so! Integer, String oder Record nicht! Bei einem statischen Array bin ich mir nicht sicher: Sowohl der Compiler als auch die Code Completion sehen die Array-Referenz als einen ziemlich schrägen Typ an:

[dcc64 Fehler] BaseClass.pas(19): E2010 Inkompatible Typen: 'BaseClass.TBaseClass<BaseClass.TBaseClass<T>.T>.: 2' und 'array[0..0] of Integer'

bei folgendem Code:

Delphi-Quellcode:

unit BaseClass;

interface
   type TBaseClass<T: class> = class abstract
      protected var
         someField: Array[0..0] of Integer;
      public
         procedure doStuff(); virtual; final;
   end;

implementation

procedure TBaseClass<T>.doStuff();
const
   someConstant: Array[0..0] of Integer = (5);
begin
   someField := someConstant;
end;

end.

Das scheint aber ein ganz anderes Problem zu sein, oder? Denn hier kann er das konkrete Problem direkt anstreichen und es ist hier die BaseClass-Unit. Ist die Klasse jedenfalls nicht generisch, dann haben sowohl Compiler als auch Code Completion kein Problem.

[jaenicke]

Das ist kein Bug. Wenn du das zuweisbar haben willst, musst du einen eigenen Typen deklarieren.

Delphi-Quellcode:

type
  TBaseClass<T: class> = class abstract
  public
    type
      TExampleArray = array [0 .. 0] of Integer;
  protected
    var
      someField: TExampleArray;
  public
    procedure doStuff(); virtual; final;
  end;

procedure TBaseClass<T>.doStuff();
const
  someConstant: TExampleArray = (5);
begin
  someField := someConstant;
end;

Denn sonst erstellt der Compiler selbst jeweils einen Typen und das sind dann eben verschiedene Typen, auch wenn die gleiche Deklaration zugrunde liegt.

Zitat von Der schöne Günther:

Ist die Klasse jedenfalls nicht generisch, dann haben sowohl Compiler als auch Code Completion kein Problem.

Richtig, das hatte ich auch genau getestet was genau die wichtigen Schritte sind, sowohl den konkreten Typ Boolean als auch den Rest.

[Der schöne Günther]

Dann haben wir ja eigentlich alles geklärt. Ich hätte nicht gedacht, dass der konkrete Typ etwas damit zu tun hat. Jetzt können wir nur noch rätseln, warum das so ist.

Ich bin kein Compilerbauer. Ich habe schon mal keine Ahnung.

[himitsu]

Delphi besitzt eine "strenge" Typprüfung.

Typen müssen identisch sein und nicht nur gleich aussehen.

Oder es müssen Konvertierungsfunktionen für diese Typen existieren, um sie einander zuweisen zu können.