Compilerbau 2024 Gruppe : absolut nicht Haskell - Simon Wittmann, Laurenz Schleicher, Julian Kraus, Ahmad Juha, Jonathan Fleischmann
Go to file
2024-07-05 01:03:58 +02:00
Klassendiagramme Corrected classdiagramm for Generators 2024-07-04 17:52:20 +02:00
output added some e2e tests for CodeGenFiles with reflections 2024-06-27 19:10:43 +02:00
presentation add some codegen stuff to presentation 2024-07-04 23:32:17 +02:00
src Checked parameters on null 2024-07-05 01:03:58 +02:00
.gitignore cleaning up 2024-07-04 21:52:34 +02:00
pom.xml add wildcard support from commandline 2024-07-04 16:30:39 +02:00
README.md added a class to test all features at once 2024-07-04 18:34:32 +02:00

CompilerNichtHaskell

Teamrollen

  • Scanner & Parser: Julian Kraus und Laurenz Schleicher
  • Semantische Analyse: Juha Ahmad
  • Code-Generierung: Simon Wittmann
  • Testen: Jonathan Fleischmann

Erbrachte Leistungen

  • Laura Schleicher: Grammatik entwickeln, Records, Statements als Liste zurückgeben, Generator, Syntactic Sugar auflösen
  • Julian Kraus: Grammatik entwickeln, Generator, Syntactic Sugar auflösen, Parser Exceptions sammeln
  • Ahmad Juha: Typcheck
  • Simon Wittmann: Codegen, Logging, CommandLine Nutzung
  • Jonathan Fleischmann:
    • Schreiben von Tests, die die einzelnen Features abdecken
    • Umwandlung der Testfiles in AST und TypedAST
    • Implementierung der Tests, die mithilfe der umgewandelten Testfiles die korrekte Umwandlung von java-File zu AST und AST zu TypedAST prüfen
    • Schreiben von Testfiles, die die einzelnen Features abdecken und gut über Reflections testbar sind
    • Implementierung eines Tools, durch das die Testfiles mithilfe von Reflections einfacher nach gewissen Kriterien überprüfbar sind
    • Implementierung von Tests, die die korrekte Umwandlung der Testfiles von java-File in class-File durch den Compiler mithilfe des Tools prüfen
    • Hinzufügen von Testfiles, die bei der Umwandlung fehlschlagen sollen
    • Implementierung von Tests, die prüfen, ob der Compiler bei den fehlerhaften Testfiles tatsächlich fehlschlägt
    • Dokumentation der Tests

Besonderheiten unserer Implementierung

  • Zugriff auf Felder nur über this-Referenz möglich
  • print()statt System.out.println()
  • keine Accessmodifier/alles ist public
  • logische Statements MÜSSEN geklammert werden, ansonsten wird ununterbrochen von links nach rechts berechnet
    (so würde z.B. (true || false == false) false zurückgeben)
  • i++ und i-- sind nur in for-Schleifen oder Statements erlaubt, --i und ++i sind generell nicht erlaubt
  • ein File kann nur eine Klasse enthalten
  • Datentypen sind auf int, boolean und char sowie Klassen beschränkt

Aufbau der Tests

Tests für den Scanner, Parser und Typechecker:

  • Die Testfiles (.java), die alle Features abdecken, sind im Ordner src/test/testFiles/ASTandTypedASTFeatures zu finden. Ihr Name gibt circa an, welches Feature / welche Features sie abdecken
  • Ihre manuell übersetzten ASTs und TypedASTs befinden sich im Ordner src/test/testFiles/ASTandTypedASTFeatures
  • Die Klasse src/test/java/ScannerParserTests.java enthält die JUnit-Tests, die die korrekte Umwandlung der Testfiles in AST durch den Compiler prüfen, indem sie den durch den Compiler generierten AST mit dem manuell erstellten AST vergleichen
  • Die Klasse src/test/java/TypingTests.java enthält die JUnit-Tests, die die korrekte Umwandlung der manuell erstellten ASTs in TypedASTs durch den Compiler prüfen, indem sie den durch den Compiler generierten TypedAST mit dem manuell erstellten TypedAST vergleichen
  • Weitere Testfiles, die nicht unbedingt auf ein bestimmtes Feature abzielen, sind im Ordner src/test/testFiles/MoreTestFiles zu finden, die manuell übersetzen ASTs und TypedASTs dazu sind im Ordner src/test/java/MoreTestResources zu finden. Die korrekte Umwandlung dieser Testfiles in AST und TypedAST wird ebenfalls durch die Klassen src/test/java/ScannerParserTests.java und src/test/java/TypingTests.java geprüft, jedoch sind die Unit-Tests hier nicht vollständig.

Tests für den gesamten Compiler:

  • Da die Kompilierung der Testfiles für den Scanner, Parser und Typechecker teilweise nicht gut mit Reflections testbar ist, gibt es extra Testfiles für das Testen des Compilers im Ordner src/test/testFiles/E2EFeatures
  • Jedes der Testfiles hat eine eigene Testklasse, welche sich im Ordner src/test/java/E2ETests/Features befindet. Diese Testklassen haben jeweils einen Namen, der sich aus E2E_ und dem Namen des Testfiles zusammensetzt. Sie prüfen mithilfe der Hilfsklasse src/test/java/E2ETests/BytecodeTestUtil.java, ob der Compiler die Testfiles korrekt in class-Files umwandelt. Die Hilfsklasse erstellt ein Class-Objekt der Klasse und implementiert Methoden, welche mit Reflections Werte aus dem Objekt auslesen und zurückgeben. Diese Werte werden dann mit den erwarteten Werten in der jeweiligen Testklasse verglichen.
  • Die Klasse src/test/java/AllE2ETests.java führt mithilfe der Klasse src/test/java/HelpClasses/TestFileTester.java alle Testklassen für die E2E-Tests der einzelnen Features aus und gibt deren Ergebnis aus. Somit muss für das E2E-Testen der gesamten Features nur diese Klasse ausgeführt werden.

Negative Tests:

  • Um zu überprüfen, dass der Compiler auch bei fehlerhaften Testfiles fehlschlägt, gibt es Testfiles im Ordner src/test/testFiles/Negative, welche nicht korrekt kompiliert werden können. Die Testfiles sin in mehrere Kategorien unterteilt, die durch die Ordnerstruktur in src/test/testFiles/Negative dargestellt werden. Für jede Kategorie gibt es eine eigene Testklasse, die sich im Ordner src/test/java/NegativeTests befindet und den gleichen Namen wie der Ordner ihrer Kategorie hat. Diese Testklassen versuchen die Testfiles ihrer Kategorie zu kompilieren und erwarten, dass der Compiler fehlschlägt.
  • Wie bei den E2E-Tests gibt es auch hier eine Klasse src/test/java/AllNegativeTests.java, die neben eigenen Tests auch alle Testklassen für die negativen Tests ausführt und deren Ergebnis ausgibt. Somit muss für das Testen der negativen Tests nur diese Klasse ausgeführt werden.
  • Bitte die Ausgabe in der Konsole ignorieren, diese Fehlermeldungen sind die erwarteten Fehlermeldungen, die der Compiler ausgeben sollte, werden in diesem Test-Fall jedoch nicht unterdrückt.