Primitiver Typ wird bei super() call nicht substituiert #328

New Issue

i21023 · 2024-04-28T17:10:52Z

i21023 commented

2024-04-28 17:10:52 +00:00

Analog zu #294

Beispiel im Anhang.

Bytecode vom Standardkonstruktor von Sub sieht folgendermaßen aus:

Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: ldc           #8                  // int 1
         3: invokestatic  #14                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
         6: invokespecial #17                 // Method Super."<init>":(Ljava/lang/Integer;)V
         9: return
        10: athrow

Hier wird also der Superkonstruktor mit java.lang.Integer aufgerufen, erwartet wird aber int

Analog zu #294 Beispiel im Anhang. Bytecode vom Standardkonstruktor von Sub sieht folgendermaßen aus: ``` Code: stack=2, locals=1, args_size=1 0: aload_0 1: ldc #8 // int 1 3: invokestatic #14 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; 6: invokespecial #17 // Method Super."<init>":(Ljava/lang/Integer;)V 9: return 10: athrow ``` Hier wird also der Superkonstruktor mit java.lang.Integer aufgerufen, erwartet wird aber int

Archiv.zip

1.0 KiB

dholle referenced this issue from a commit

2024-04-28 17:25:26 +00:00

Fix #328

dholle closed this issue

2024-04-28 17:25:27 +00:00

dholle reopened this issue

2024-04-28 18:17:52 +00:00

dholle added the

Codegen

confirmed

in progress

labels 2024-04-28 18:18:05 +00:00

dholle referenced this issue from a commit

2024-04-29 08:25:06 +00:00

Add bug for #328

dholle commented

2024-04-29 09:38:59 +00:00

@pl Ich glaube die signature constraints werden nie ausgewertet. Ich generiere die hier:

		src/main/java/de/dhbwstuttgart/typeinference/typeAlgo/TYPEStmt.java
		Line 602 in 2c66a1d6e6
	
				        constraintsSet.addOderConstraint(methodConstraints);

@pl Ich glaube die signature constraints werden nie ausgewertet. Ich generiere die hier: https://gitea.hb.dhbw-stuttgart.de/JavaTX/JavaCompilerCore/src/commit/2c66a1d6e68d3ff0ffb2d1c774cbda0db071d592/src/main/java/de/dhbwstuttgart/typeinference/typeAlgo/TYPEStmt.java#L602

pl referenced this issue from a commit

2024-05-02 14:51:16 +00:00

Bei diesem und vorigen Commit wurde der Bug #328

pl commented

2024-05-02 14:52:48 +00:00

71dfe5d9e1 lost das Problem

src/main/java/de/dhbwstuttgart/typeinference/unify/TypeUnifyTask.java
in der Methode copute wurden die methodSignatureConstraints der bereits zu Beginn
aufegloesten einer Oder Constraints in die Methodconstraints der Unifikation geschrieben
Elementtyp der linken Seiten der methodSignatureConstraints wurden von RefTypeOrTPHOrWildcardOrGeneric auf
TypePlaceholder geaendert, weil dort nur TypePlaceholder geaendert.
src/main/java/de/dhbwstuttgart/parser/SyntaxTreeGenerator/SyntaxTreeGenerator.java
in der Methode prepareBlock wurde der Typ des Rückgabewerts des supercalls von Void auf eine
Freshtpevar gesetzt.
src/main/java/de/dhbwstuttgart/typeinference/unify/TypeUnifyTask.java
in der unify2-Methode wurde am Ende der Aufruf der Substitution nach Hinzufuegen der
Methodconstraints auskommentiert -> hat zu nicht geloesten Constraints gefuehrt.

71dfe5d9e1b8e9a7fc60ff4c372cd0080360b520 lost das Problem 1. src/main/java/de/dhbwstuttgart/typeinference/unify/TypeUnifyTask.java in der Methode copute wurden die methodSignatureConstraints der bereits zu Beginn aufegloesten einer Oder Constraints in die Methodconstraints der Unifikation geschrieben 2. Elementtyp der linken Seiten der methodSignatureConstraints wurden von RefTypeOrTPHOrWildcardOrGeneric auf TypePlaceholder geaendert, weil dort nur TypePlaceholder geaendert. 3. src/main/java/de/dhbwstuttgart/parser/SyntaxTreeGenerator/SyntaxTreeGenerator.java in der Methode prepareBlock wurde der Typ des Rückgabewerts des supercalls von Void auf eine Freshtpevar gesetzt. 4. src/main/java/de/dhbwstuttgart/typeinference/unify/TypeUnifyTask.java in der unify2-Methode wurde am Ende der Aufruf der Substitution nach Hinzufuegen der Methodconstraints auskommentiert -> hat zu nicht geloesten Constraints gefuehrt.

pl closed this issue

2024-05-02 14:52:49 +00:00

i21023 commented

2024-05-13 16:54:09 +00:00

Das Problem besteht weiterhin

hierzu folgendes Beispiel:

Datei Super.java

public class Super {
    public Super(int a){
    }
}

Datei Sub.jav

import java.lang.Integer;

public class Sub extends Super{
    public Sub(a){
        super(a);
    }
}

Der Bytecode (decompiled) von Sub.jav sieht nachher so aus:

// Source code is decompiled from a .class file using FernFlower decompiler.
public class Sub extends Super {
   public Sub(Integer var1) {
      super(var1);
   }
}

Es für den Parameter a wird also java.lang.Integer statt int inferiert.

Das Problem besteht weiterhin hierzu folgendes Beispiel: Datei Super.java ```java public class Super { public Super(int a){ } } ``` Datei Sub.jav ```java import java.lang.Integer; public class Sub extends Super{ public Sub(a){ super(a); } } ``` Der Bytecode (decompiled) von Sub.jav sieht nachher so aus: ```java // Source code is decompiled from a .class file using FernFlower decompiler. public class Sub extends Super { public Sub(Integer var1) { super(var1); } } ``` Es für den Parameter a wird also java.lang.Integer statt int inferiert.

i21023 reopened this issue

2024-05-13 16:54:09 +00:00

Sign in to join this conversation.