Merge pull request #26 from Java-rs/codegen

Updated Documentation

Author: ArtInLines

docs/Project-Doc.md

@@ -1,22 +1,24 @@
-## Supported types
-
-Unterstützte Typen sind in [Types](../lib/src/types.rs) definiert.
-Mögliche Kombinationen sind den [Tests](../lib/testcases) zu entnehmen.
-
-
 ## Parser
 
-Geschrieben von: Viktoria Gönnheimer, Sander Stella
+Geschrieben von: Tori Gönnheimer, Sander Stella
 
-Der Parser akzeptiert den text eines Java Programms und gibt einen Abstract Syntax Tree (AST) zurück.
+Ausführliche Mithilfe (v.a. beim Schreiben der Grammatik): Val Richter
+
+Der Parser akzeptiert den Text eines Java Programs und gibt einen Abstract Syntax Tree (AST) zurück.
 Dafür wird die Libray [pest.rs](https://pest.rs/) verwendet, um das Inital Parsing durchzufüren.
-Für dieses inital parsing nutzt pest unsere vorher definiete Gramatik. Bei der Gramatik wurde sich primär and der Vorlesugn orientiert mit signifikaten Abänderungen um das parsing zu vereinfachen, sowie den Spezifikationen der Library nachzukommen.
+Für dieses inital Parsing nutzt pest unsere vorher definiete Gramatik.
+
+Bei der Grammatik wurde sich Anfangs an den Hilfsmitteln der Vorlesung orientiert. Später wurde diese allerdings neu geschrieben, um sich stärker am verwendeten AST zu orientieren. Dadurch wurde auch die Implementation des restlichen Parsers sehr viel erleichtert.
 Das Egebnis, welches Pest zurückgibt wird von uneren Parser-Funktionen analysiert und umgewandelt.
 Dabei wird wie folgt vorgegangenen:
-- Eine Funktion schaut sich die aktuelle Regel an
-- Es wird der Entsprechende Code zu dieser Regel ausgeführt
-- Sofern Subregeln in dieser Regel vorkommen, wird die entsprechende Funktion aufgerufen
 
+-   Eine Funktion schaut sich die aktuelle Regel an
+-   Es wird der Entsprechende Code zu dieser Regel ausgeführt
+-   Sofern Subregeln in dieser Regel vorkommen, wird die entsprechende Funktion aufgerufen
+
+-   Eine Funktion schaut sich die aktuelle Regel an
+-   Es wird der entsprechende Code zu dieser Regel ausgeführt
+-   Sofern Subregeln in dieser Regel vorkommen wird die entsprechende Funktion aufgerufen
 
 ## Typechecker
 
@@ -57,47 +59,72 @@ Folgende Fehler werden vom Typechecker erkannt:
 
 ## Codegenerierung
 
-ByteCode-Umwandlung, Bugfixes, StackSize und viele Verbesserungen: Val Richter
+Geschrieben von: Marion Hinkel und Benedikt Brandmaier im Pair Programming
+
+StackMapTable-Implementation, Mithilfe bei Transformation von DIR zu Bytes und sonstigem Bugfixing: Val Richter
 
-Definition DIR(Duck Intermediate Representation), ConstantPool, LocalVarPool, Methoden zur Instruction-generierung, BugFixes, etwas ByteCode-Umwandlung und Umwandlung relativer in absolute Jumps: Marion Hinkel und Benedikt Brandmaier im Pair Programming
+Zur Bytecode-Generierung wird der Typed Abstract Syntax Tree (TAST) in Java Bytecode umgewandelt.
+Es wurden keine Libraries (wie z.B. [ASM](https://asm.ow2.io/javadoc/)) verwendet.
+Für die Codegenerierung wird eine Intermediate Representation (IR) genutzt, die eine Class-ähnliche Struktur
+(mit Konstantenpool, LocalVarpool, Methoden mit Code als Instruktionen, etc.) besitzt.
+Diese IR wird dann komplett manuell in Java Bytecode übersetzt. Dies hat sehr viel Zeit gekostet,
+da z.B. die Stack-Size, der Konstantenpool, LocalVarPool und alle Jumps manuell berechnet werden mussten.
 
-Zur Bytecode-generierung wird der Typed Abstract Syntax Tree(TAST) in Java Bytecode komplett selber
-umgewandelt. Dafür wird eine Intermediate Representation (IR) genutzt, die eine Class-ähnliche Struktur(mit Konstantenpool, LocalVarpool, Methoden mit Code als Instruktionen, etc.)
-besitzt. Diese IR wird dann komplett manuell in Java Bytecode übersetzt. Dies hat dem Code-gen Team sehr viel
-Zeit gekostet, da z.B. die Stack-Size, der Konstantenpool, LocalVarpool und die Jumps manuell berechnet werden mussten.
+Zudem hatten wir zeitweise eigene Instructions für relative Jumps implementiert, die wir dann in absolute Jumps umgerechnet haben,
+da wir dachten, dass die JVM keine relativen Jumps unterstützt. Dieser Glauben kam daher, dass die Ausgabe von `javap` die
+Ziel-Adressen von Jumps immer als absolute Adressen angezeigt hat. Es stellte sich dann aber heraus, dass die JVM eigentlich
+nur relative Jumps versteht und nur javap diese schon umgerechnet dargestellt hat. Aber selbst danch waren die relativen Jumps
+noch sehr fehleranfällig und hatten häufig off-by-one Errors.
 
-Zudem hatten wir zeitweise eigene Relative Instructions implementiert, da wir dachten, dass die JVM keine relativen Jumps
-unterstützt, hatten dann allerdings mit Try-and-Error herausgefunden, dass javap sich die absoluten Addressen ausrechnet
-und für die JVM normale jumps als relative Jumps behandelt. Auch die relativen Jumps waren aber sehr fehleranfällig und
-hatten häufig off-by-one Errors.
+Zudem musste eine [StackMapTable](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.4) per Hand implementiert werden,
+da die JVM unsere Klassen sonst nicht geladen hat. Die Implementation dieser war ebenfalls sehr zeitaufwendig, da an sich ein ganzer
+Typchecker für den generierten Bytecode implementiert werden musste, um korrekte StackMapTables zu generieren.
 
-Zudem musste eine StackMapTable implementiert werden, da die JVM sonst unsere Klassen nicht lädt.
-Das Troubleshooten von Testfehlern war auch sehr aufwending da oft javap gar nicht erst den Fehler im Klassencode ausgab
+Das Troubleshooten von Testfehlern war auch sehr aufwendig da oft javap gar nicht erst den Fehler im Klassencode ausgab
 und wir mit einem Hex-Editor die Klassen von Hand analysieren mussten, da es auch kein anderes Tool gab, um solche Fehler
-auszugeben und die Zeit fehlte ein Eigenes zu schreiben.
+auszugeben und die Zeit fehlte ein eigenes Tool dafür zu schreiben.
 
-Da es auch keine Dokumentation gibt, die in etwa zeigt, welcher Bytecode für welche Operationen genutzt wird, mussten wir
+Da es auch keine gute Dokumentation gibt, die in etwa zeigt, welcher Bytecode für welche Operationen genutzt wird, mussten wir
 uns die Bytecode-Spezifikationen anschauen und sehr viel mit Tools wie javap und [godbolt](https://godbolt.org/) arbeiten
-in die wir manuell Java Code eingeben und schauten, was für Bytecode bei verschiedenen Operationenkombinationen generiert
-wird, was sehr zeitaufwendig war.
-
-Auch sehr schwierig war die Implementation einer StackMapTable, da Java diese erwartet. Diese ist eine Tabelle, die für
-jede Instruktion die Typen der Elemente auf dem Stack in komprimiertem Format angibt. Diese Tabelle muss manuell
-erstellt werden und über die Typen aller Variablen, die in den Stack geschrieben wurden Bescheid wissen.
+(wir haben auch https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-3.html genutzt, aber diese Dokumentation nutzt
+sehr spezifische Instruktionen und wurde deswegen selten genutzt) in die wir manuell Java Code eingeben konnten, um zu sehen,
+welcher Bytecode bei verschiedenen Operationskombinationen generiert wird, was sehr zeitaufwendig war.
 
 ## Testing
 
-Das Testen des Codegens war sehr aufwendig, er besteht aus diesen Schritten:
-
-1. Ein handgeschriebener TAST wird geladen
-2. Eine Java Klasse wird erstellt die jede Methode im TAST aufruft
-3. Die java Klasse wird mit javac kompiliert und ausgeführt, wobei die Ausgabe in einer Variable gespeichert wird
-4. Fürs Debugging wird die Java Klasse mit javap in Bytecode umgewandelt und in eine Datei geschrieben
-5. Der TAST wird in eine DIR umgewandelt und zu Bytecode umgewandelt
-6. Der Bytecode wird in eine .class-Datei geschrieben
-7. Die .class-Datei wird mit javap in Bytecode umgewandelt und in eine Datei geschrieben
-8. Die vom Codegen generierte .class-Datei wird ausgeführt und die Ausgabe in einer Variable gespeichert
-9. Die Ausgaben der richtigen Java Klasse und der vom Codegen generierten Klasse werden verglichen
+Geschrieben von: Val Richter
+
+Jeder Test besteht aus einer Java-Klasse (liegt jeweils in `lib/testcases`) und aus dem dazugehörigen getypten AST, welcher für jeden Test per Hand geschrieben wurde. Mit diesen beiden Teilen testen wir dann den Parser, Typchecker und die Codegenerierung. Außerdem testen wir auch, dass der handgeschriebene TAST korrekt ist. Wie diese Tests funktionieren, wird im Folgenden ausgeführt.
+
+Um zu testen, dass die handgeschriebenen TASTs korrekt sind, wird aus dem TAST ein syntaktisch korrektes Java-Programm geschrieben. Alle Typinformationen des TAST werden dabei ignoriert.
+Das so erstellte Java-Programm wird dann in eine Datei geschrieben und mit `javac` kompiliert. Daraufhin wird überprüft, dass die kompilierte `.class`-Datei identisch mit der `.class`-Datei ist,
+die man beim Kompilieren des originalen Java-Programms erhält. Eine nervige Besonderheit bei diesem Vorgehen ist, dass der vom AST generierte Java-Code die originale Java-Datei überschreiben muss,
+da der `javac` Compiler sonst minimal unterschiedliche `.class`-Dateien schreibt. Trotzdem war dieser Test sehr hilfreich, da beim handschriftlichen Schreiben der teilweise sehr großen TASTs,
+sehr oft kleine Fehler gemacht wurden, die ansonsten nur schwer zu finden wären.
+
+Außerdem schreiben wir bei dem Test des TASTs den erwarteten AST und TAST als `.json`-Dateien in den `lib/testcases` Ordner. Diese Dateien dienen vor allen bei der Implementation der anderen Teile des Compilers, da somit leicht sichtbar ist, wie der erwartete AST bzw. TAST aussehen sollten für den jeweiligen Test.
+
+Das Testen des Parsers war relativ leicht. Hier musste nur die jeweilige Java-Datei gelesen und in den Parser gegeben werden. Sobald dieser dann den erstellten AST zurück gibt, kann überprüft werden, ob er identisch mit dem handgeschriebenen TAST ist. Dabei werden alle Typinformationen vom TAST vorher entfernt (wodurch wir den AST erhalten), weil der Parser ja noch keine Typinformationen hinzufügt.
+
+Das Testen des Typcheckers läuft ähnlich ab. Der handgeschriebene TAST dient als erwartete Ausgabe des Typcheckers. Der AST, der als Eingabe für den Typchecker dient, wird über Entfernen der Typinformationen beim TAST generiert.
+
+Das Testen des Codegens war dagegen sehr viel aufwendiger. Die Eingabe für die Codegenerierung ist mit den handgeschriebenen TASTs bereits gegeben. Um die Ausgabe zu überprüfen, hätte man allerdings die erwarteten Bytes per Hand aufschreiben müssen. Das wäre zu aufwendig und fehleranfällig gewesen. Stattdessen testen wir, dass die von uns geschriebene `.class`-Datei sich identisch mit der von `javac` erstellten `.class`-Datei verhält.
+
+Dafür wurde zuerst die originale Java-Datei kompiliert. Zusätzlich wird eine Test-Datei geschrieben, welche eine `main` Funktion hat und alle Methoden der originalen Java-Datei aufruft. Über die handgeschriebenen TASTs wissen wir, welche Methoden die Klasse besitzt und welche Eingaben sie erwartet und was sie ausgibt. Die Eingaben werden pseudo-zufällig für den Test generiert. Falls die Methoden einen Wert ausgibt, schreibt die `main` Funktion der Test-Datei diesen Ausgabewert in die Konsole. Damit erhalten wir das erwartete Verhalten der originalen Java-Klasse.
+
+Im nächsten Schritt überschreiben wir nun die `.class`-Datei der originalen Java-Datei mit den Bytes, die wir aus der Codegenerierung erhalten. Dann können wir Test-Datei nochmal ausführen. Diesmal versucht java aber natürlich die von uns geschriebene `.class`-Datei zu lesen und zu benutzen. Wenn die Test-klasse dann die selben Ausgaben macht, wissen wir, dass sich unsere `.class`-Datei genauso wie die originale `.class`-Datei verhält und unsere Codegenerierung entsprechend richtig funktioniert.
+
+Zusätzlich nutzen wir in diesem Test auch das mit Java mitgelieferte Tool `javap`, welches uns erlaubt den originalen und den von uns generierten Bytecode zu disassemblieren. Wir schreiben die Ausgabe von `javap` dann in jeweils eine Datei (eine Datei für die originale von `javac` kompilierte Klasse und eine Datei für die von uns kompilierte Klasse). Diese Ausgaben sind zwar für den Test nicht notwendig, haben aber sehr geholfen bei Fehlersuche und Fehlerbehebung.
+
+## Supported types
+
+Unterstützte Typen sind in [Types](../lib/src/types.rs) definiert.
+Mögliche Kombinationen sind den [Tests](../lib/testcases) zu entnehmen.
+
+## Supported types
+
+Unterstützte Typen sind in [Types](../lib/src/types.rs) definiert.
+Mögliche Kombinationen sind den [Tests](../lib/testcases) zu entnehmen.
 
 ## AST-Definition
 

docs/README.md

@@ -4,7 +4,7 @@ There are three parts to the documentation:
 
 ## 1. Short user documentation
 
-[This](./User-Doc.md) is a short doument, detailing how to compile and run each separate part of the compiler.
+[This](./User-Doc.md) is a short document, detailing how to compile and run each separate part of the compiler.
 
 ## 2. UML Class-Diagram for AST
 

docs/User-Doc.md

@@ -7,6 +7,7 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
 ```
 
 -   [JDK 20](https://www.oracle.com/java/technologies/downloads/) (Wird in Tests für die Validierung des Codegens benötigt)
+-   `java`, `javac` und `javap` müssen dabei für die Tests der Codegenerierung im Pfad sein, damit diese vom Test genutzt werden können.
 
 # Ausführen
 
@@ -22,22 +23,28 @@ cargo r -r -- <input_file> [<output_file>]
 
 ## Parser
 
-2. Parser tests ausführen: `cargo test --lib test_parser`
+2. Parser Tests ausführen: `cargo test --lib test_parser`
 
 Spezifischen Test ausführen: `cargo test --lib <test_name>::test_parser`
 
 ## Typchecker
 
-2. Typechecker tests ausführen: `cargo test --lib test_typechecker`
+2. Typechecker Tests ausführen: `cargo test --lib test_typechecker`
 
 Spezifischen Test ausführen: `cargo test --lib <test_name>::test_typechecker`
 
 ## Codegenerierung
 
-2. Codegenerierung tests ausführen: `cargo test --lib test_codegen`
+2. Codegenerierung Tests ausführen: `cargo test --lib test_codegen`
 
 Spezifischen Test ausführen: `cargo test --lib <test_name>::test_codegen`
 
+## TAST
+
+2. Ausführung der Tests von den handgeschriebenen TASTs: `cargo test --lib test_class`
+
+Spezifischen Test ausführen: `cargo test --lib <test_name>::test_class`
+
 ## Testing
 
-Zur ausführung aller tests: `cargo test --lib`. Dabei sollte beachtet werden, dass die Tests teilweise die selben Dateien schreiben und entsprechend Probleme aufkommen können, wenn alle Tests auf einmal ausgeführt werden. Diese Probleme treten nicht auf, wenn die Teile des Compilers (Parser, Typchecker, Codegenerierung) einzeln getestet werden.
+Zur ausführung aller Tests: `cargo test --lib`. Dabei sollte beachtet werden, dass die Tests teilweise die selben Dateien schreiben und entsprechend Probleme aufkommen können, wenn alle Tests gleichzeitig ausgeführt werden. Diese Probleme treten nicht auf, wenn die Teile des Compilers (Parser, Typchecker, Codegenerierung) einzeln getestet werden.

lib/src/codegen/ir.rs

@@ -71,6 +71,7 @@ impl DIR {
 
         result.extend_from_slice(&[0, 0]);
         result.extend_from_slice(&[]);
+        println!("Generated bytecode succesfully!🎉💾");
         result
     }
 }

lib/src/parser/JavaGrammar.pest

@@ -34,12 +34,10 @@ ReturnStmt = {"return" ~ Expr ~ ";"}
 
 WhileStmt = {"while" ~ "(" ~ Expr ~ ")" ~ Stmt}
 
-// @Question: Is this a correct and easy-to-use definition?
 IfElseStmt = {IfStmt ~ "else" ~ Stmt}
 
 IfStmt = {"if" ~ "(" ~ Expr ~ ")" ~ Stmt}
 
-// @Cleanup: Can maybe be unified with FieldVarDecl and AssignExpr?
 LocalVarDeclStmt = {JType ~ Identifier ~ ("="~Expr)? ~ ("," ~ Identifier ~ ("="~Expr)?)* ~ ";"}
 
 StmtExpr = {AssignExpr | NewExpr | MethodCallExpr}

lib/src/parser/parser.rs

@@ -23,6 +23,7 @@ pub fn parse_programm(file: &str) -> Result<Vec<Class>, Error<Rule>> {
         panic!();
     }
     let pased_clases = prg.into_inner().map(parse_class).collect();
+    println!("Parsed program successfully!🎉✍️");
     Ok(pased_clases)
 }
 
@@ -124,51 +125,6 @@ fn parse_BlockStmt(pair: Pair<Rule>) -> Vec<Stmt> {
             }
 
             result
-            /*
-            let first = inner.next();
-            if (first.is_none()) {
-                return vec![];
-            }
-            let first = first.unwrap();
-
-            let result = vec![];
-            for first in inner {
-                match first.as_rule() {
-                    /*
-                    Rule::JType => {
-                        let jtype = parse_Type(first);
-                        let var_decels = inner.next().unwrap().into_inner();
-                        var_decels
-                            .map(|x| {
-                                let mut inner = x.into_inner();
-                                let other_name = next_id(&mut inner);
-                                match inner.next() {
-                                    None => {
-                                         Stmt::LocalVarDecl(jtype.clone(), other_name)
-                                    }
-                                    Some(expresion) => vec![
-                                        Stmt::LocalVarDecl(jtype.clone(), other_name.clone()),
-                                        Stmt::StmtExprStmt(StmtExpr::Assign(
-                                            other_name,
-                                            parse_expr(expresion),
-                                        )),
-                                    ],
-                                }
-                            })
-                            .flatten()
-                            .collect()
-                    }
-
-                     */
-                    Rule::Stmt => parse_Stmt(first.into_inner().next().unwrap()),
-                    _ => {
-                        dbg!(first.as_rule());
-                        unreachable!()
-                    }
-                }
-            }
-            result
-            */
         }
         _ => {
             unreachable!()
@@ -219,19 +175,36 @@ fn parse_Stmt(pair: Pair<Rule>) -> Vec<Stmt> {
         Rule::LocalVarDeclStmt => {
             let mut inners = pair.into_inner();
 
+            let mut result = vec![];
             let typeJ = parse_Type(inners.next().unwrap());
-            let var_name = next_id(&mut inners);
-            //   StmtExprStmt
-            let lVD = Stmt::LocalVarDecl(typeJ, var_name.clone());
 
-            match inners.next() {
-                None => vec![lVD],
-                Some(expr_pair) => {
-                    let expr =
-                        StmtExpr::Assign(Expr::LocalOrFieldVar(var_name), parse_expr(expr_pair));
-                    vec![lVD, Stmt::StmtExprStmt(expr)]
+            let mut last_var_name = None;
+            for inner in inners {
+                match inner.as_rule() {
+                    Rule::Identifier => {
+                        if last_var_name.is_some() {
+                            result.push(Stmt::LocalVarDecl(typeJ.clone(), last_var_name.unwrap()));
+                        }
+                        last_var_name = Some(inner.as_str().trim().to_string());
+                    }
+                    Rule::Expr => {
+                        result.push(Stmt::LocalVarDecl(
+                            typeJ.clone(),
+                            last_var_name.as_ref().unwrap().clone(),
+                        ));
+                        result.push(Stmt::StmtExprStmt(StmtExpr::Assign(
+                            Expr::LocalOrFieldVar(last_var_name.unwrap()),
+                            parse_expr(inner),
+                        )));
+                        last_var_name = None;
+                    }
+                    _ => unreachable!(),
                 }
             }
+            if last_var_name.is_some() {
+                result.push(Stmt::LocalVarDecl(typeJ, last_var_name.unwrap()));
+            }
+            result
         }
         Rule::StmtExpr => {
             vec![Stmt::StmtExprStmt(parse_StmtExpr(