Methodenaufruf beim Aufruf überladener Methoden teilweise falsch #332

New Issue

i21023 · 2024-05-13T17:52:04Z

i21023 commented

2024-05-13 17:52:04 +00:00

Es gab den gleichen Bug schon einmal #307, inzwischen tritt er allerdings nur noch auf, wenn ich Java und Jav Dateien mixe. Zumindest hab ich den alten Bug #307 jetzt einige male ausprobiert und er ist nicht aufgetreten. Aber da der Bug nur manchmal auftritt habe ich vielleicht einfach nicht lange genug getestet.

Der Testaufbau ist ein bisschen umständlich, da es zirkuläre Imports zwischen den Java und Jav Dateien gibt.

Daher muss die Jav Datei zusätzlich auch als Java Datei vorliegen, damit man es initial compilerbar ist.

Ich habe die notwendigen Dateien in den Anhang geladen.
Auf einem unixoiden System sollte mit dem folgenden Befehl der Test automatisiert werden können. Also zip entpacken, in den Ordner gehen und Befehl ausführen.

rm -f *.class && javac Main.java && java -jar JavaTXCompiler.jar Foo.jav && java Main

Achtung, es sollten keine anderen Class Dateien im aktuellen Ordner liegen, sonst werden diese gelöscht!

Die Ausgabe des Befehls variiert wenn man ihn öfter ausführt. Die korrekte Ausgabe wäre "Foo", es wird aber teilweise auch "Object" ausgegeben. Also irgendetwas stimmt wohl in der Typinferenz nicht.

TxGenerics Foo: []
JavaGenerics Foo: []
TxGenerics Foo: []
generating Foo.class file ...
Foo.class
Foo.class file generated
Foo

TxGenerics Foo: []
JavaGenerics Foo: []
TxGenerics Foo: []
generating Foo.class file ...
Foo.class
Foo.class file generated
Object

Es gab den gleichen Bug schon einmal #307, inzwischen tritt er allerdings nur noch auf, wenn ich Java und Jav Dateien mixe. Zumindest hab ich den alten Bug #307 jetzt einige male ausprobiert und er ist nicht aufgetreten. Aber da der Bug nur manchmal auftritt habe ich vielleicht einfach nicht lange genug getestet. Der Testaufbau ist ein bisschen umständlich, da es zirkuläre Imports zwischen den Java und Jav Dateien gibt. Daher muss die Jav Datei zusätzlich auch als Java Datei vorliegen, damit man es initial compilerbar ist. Ich habe die notwendigen Dateien in den Anhang geladen. Auf einem unixoiden System sollte mit dem folgenden Befehl der Test automatisiert werden können. Also zip entpacken, in den Ordner gehen und Befehl ausführen. `rm -f *.class && javac Main.java && java -jar JavaTXCompiler.jar Foo.jav && java Main` Achtung, es sollten keine anderen Class Dateien im aktuellen Ordner liegen, sonst werden diese gelöscht! Die Ausgabe des Befehls variiert wenn man ihn öfter ausführt. Die korrekte Ausgabe wäre "Foo", es wird aber teilweise auch "Object" ausgegeben. Also irgendetwas stimmt wohl in der Typinferenz nicht. ``` TxGenerics Foo: [] JavaGenerics Foo: [] TxGenerics Foo: [] generating Foo.class file ... Foo.class Foo.class file generated Foo ``` ``` TxGenerics Foo: [] JavaGenerics Foo: [] TxGenerics Foo: [] generating Foo.class file ... Foo.class Foo.class file generated Object ```

Archiv 2.zip

20 MiB

pl was assigned by i21023

2024-05-16 14:38:05 +00:00

pl commented

2024-05-17 15:39:53 +00:00

Ich welchen commit gibt es diesen Bug? Bei mir ist die Datei nicht vorhanden

i21023 commented

2024-05-17 15:47:21 +00:00

Der Bug ist im aktuellen Commit 974582f7e5 noch vorhanden. Die Dateien sind im Anhang vom Issue als Archiv 2.zip.

Der Bug ist im aktuellen Commit 974582f7e5 noch vorhanden. Die Dateien sind im Anhang vom Issue als `Archiv 2.zip`.

i21023 commented

2024-05-17 16:02:53 +00:00

Eigentlich geht es auch nur um die Foo.jav Datei, du musst also nur diese Datei mit dem Java-TX-Compiler aufrufen, dann müsste er die visit Methode machmal mit dem Typ Foo und manchmal mit dem Typ Object aufrufen. Die anderen Dateien sollten schon compiliert im Archiv liegen.

Eigentlich geht es auch nur um die `Foo.jav` Datei, du musst also nur diese Datei mit dem Java-TX-Compiler aufrufen, dann müsste er die visit Methode machmal mit dem Typ Foo und manchmal mit dem Typ Object aufrufen. Die anderen Dateien sollten schon compiliert im Archiv liegen.

dholle referenced this issue

2024-05-23 12:24:21 +00:00

Falscher Bytecode bei Konstruktoraufruf mit Subtyp #329

dholle was assigned by pl

2024-05-28 14:35:05 +00:00

pl commented

2024-05-28 14:35:15 +00:00

In der Tat muss das Problem im Bytecodegenerierer liegen. Das Resultset hat zwei Lösungen

class Foo {

Foo()({
})::TPH X
TPH N accept(Bar b)({
((b)::Bar.visit Signature: [TPH P, TPH Q]((this)::TPH O))::TPH R;
return;
})::TPH T

Foo()({
super(()) Signature: [TPH V];
})::TPH W

}

RESULT Final: [
[(TPH R = void), (TPH P = java.lang.Object), (TPH N = void), (TPH O = Foo), (TPH Q = void)],
[(TPH Q = void), (TPH N = void), (TPH P = Foo), (TPH R = void), (TPH O = Foo)]]

In der Tat muss das Problem im Bytecodegenerierer liegen. Das Resultset hat zwei Lösungen class Foo { Foo()({ })::TPH X TPH N accept(Bar b)({ ((b)::Bar.visit Signature: [TPH P, TPH Q]((this)::TPH O))::TPH R; return; })::TPH T Foo()({ super(()) Signature: [TPH V]; })::TPH W } RESULT Final: [ [(TPH R = void), (TPH P = java.lang.Object), (TPH N = void), (TPH O = Foo), (TPH Q = void)], [(TPH Q = void), (TPH N = void), (TPH P = Foo), (TPH R = void), (TPH O = Foo)]]

dholle commented

2024-05-29 13:45:42 +00:00

Ich kann die Methode nicht überladen weil die dann zweimal die selbe Signatur hat. Sieht so aus als würde ich hier die erste Lösung nehmen und die andere wegschmeißen.

Wieso sollte TPH P hier jemals Object sein? this hat doch immer den Typ Foo. Ist die Lösung vielleicht zu generell? Es ist ja beides richtig, nur ist Foo halt der konkretere Typ.

Ich kann die Methode nicht überladen weil die dann zweimal die selbe Signatur hat. Sieht so aus als würde ich hier die erste Lösung nehmen und die andere wegschmeißen. Wieso sollte `TPH P` hier jemals `Object` sein? `this` hat doch immer den Typ `Foo`. Ist die Lösung vielleicht zu generell? Es ist ja beides richtig, nur ist `Foo` halt der konkretere Typ.

pl commented

2024-05-31 12:27:35 +00:00

Das liegt daran, dass in Bar.java:

public class Bar{

void visit(Object o){
    System.out.println("Object");
}

void visit(Foo f){
    System.out.println("Foo");
}

}
visit eine überladene Methode ist und damit P = Object eine Altenative ist.

Das liegt daran, dass in Bar.java: public class Bar{ void visit(Object o){ System.out.println("Object"); } void visit(Foo f){ System.out.println("Foo"); } } visit eine überladene Methode ist und damit P = Object eine Altenative ist.

pl commented

2024-05-31 15:00:55 +00:00

Habe gerade nochmals mit Julian gesprochen. Es müsste hier in der Tat immer die speziellste Methode ausgesucht werden. Bei der Unifikation wird das schwierig, weil bei ungetypten Überladungen die Typen ja noch nicht bekannt sind. Kann man die speziellste Typisierung bei der Bytecodegenerierung noch feststellen?

dholle commented

2024-06-04 09:33:16 +00:00

Ich kann ohne weiteres feststellen ob eine Methode mit einer anderen kollidieren würde. Ich denke mal man müsste die TPHs der beiden Methoden vergleichen und da irgendwie feststellen welche konkreter ist. Was die Details angeht bin ich mir aber nicht sicher, gibt es eine gute Metrik um festzustellen welche Methode konkreter ist?

pl commented

2024-06-05 11:48:04 +00:00

Man muss während der Umwandlung vom AST -> TargetAST die TPHs der jeweiligen Methdenaufrufe finden.
Der Methodenaufruf wird nur für den speziellsten Fall generiert
Es werden Überladungen nur den Fällen konstruiert, in denen es keinen speziellsten Fall gibt.

Man muss während der Umwandlung vom AST -> TargetAST die TPHs der jeweiligen Methdenaufrufe finden. Der Methodenaufruf wird nur für den speziellsten Fall generiert Es werden Überladungen nur den Fällen konstruiert, in denen es keinen speziellsten Fall gibt.

dholle referenced this issue from a commit

2024-06-13 15:23:23 +00:00

Work on Bug #332

Sign in to join this conversation.