JavaTX/JavaCompilerCore
2
0
Fork 3
Code Issues 99 Pull Requests Actions Packages Projects Releases Wiki Activity

Methodenaufruf beim Aufruf überladener Methoden teilweise falsch #332

New Issue
Open
opened 2024-05-13 17:52:04 +00:00 by i21023 · 9 comments
i21023 commented 2024-05-13 17:52:04 +00:00
Collaborator
Copy Link

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
Owner
Copy Link

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

Ich welchen commit gibt es diesen Bug? Bei mir ist die Datei nicht vorhanden
i21023 commented 2024-05-17 15:47:21 +00:00
Author
Collaborator
Copy Link

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
Author
Collaborator
Copy Link

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 was assigned by pl 2024-05-28 14:35:05 +00:00
pl commented 2024-05-28 14:35:15 +00:00
Owner
Copy Link

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
Owner
Copy Link

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
Owner
Copy Link

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
Owner
Copy Link

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?

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
Owner
Copy Link

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?

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
Owner
Copy Link

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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Codegen

   
confirmed

   
duplicate

   
Eclipse-Plugin

   
Feature Request

   
generics

   
in progress

   
invalid

   
JavaCompilerCore

   
needs info

   
Parser

   
Trash

   
Type

   
Unify

   
won't fix

   
works for me
No Label
Codegen
confirmed
duplicate
Eclipse-Plugin
Feature Request
generics
in progress
invalid
JavaCompilerCore
needs info
Parser
Trash
Type
Unify
won't fix
works for me
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
pl
dholle
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: JavaTX/JavaCompilerCore#332
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?