Compilerbau 2024 Gruppe : absolut nicht Haskell - Simon Wittmann, Laurenz Schleicher, Julian Kraus, Ahmad Juha, Jonathan Fleischmann
Go to file
2024-07-03 22:15:31 +02:00
output added some e2e tests for CodeGenFiles with reflections 2024-06-27 19:10:43 +02:00
presentation Added folder presentation and init the slidev presentation 2024-06-24 21:33:40 +02:00
src Merge branch 'refs/heads/main' into testsuites 2024-07-03 22:15:31 +02:00
.gitignore added .ide to gitignore 2024-04-24 15:26:54 +02:00
pom.xml cleaned a bit and added implementation in CodegeneratorTests which executes all the codeGen tests 2024-06-29 16:50:06 +02:00
README.md Merge branch 'refs/heads/main' into testsuites 2024-07-03 22:15:31 +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 und Tool für ASM
  • 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

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

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 ByteCode_ 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 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.