Compilerbau 2024 Gruppe : absolut nicht Haskell - Simon Wittmann, Laurenz Schleicher, Julian Kraus, Ahmad Juha, Jonathan Fleischmann
Go to file
2024-07-05 11:42:40 +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 Added stuff for präsi 2024-07-05 11:42:40 +02:00
src Merge remote-tracking branch 'origin/main' 2024-07-05 11:41:14 +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 cleaned up tests 2024-07-05 10:43:34 +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: Testfiles, manuelle übersetzung in AST und TypedAST, JUnit-Tests für Scanner, Parser und Typecheck und Compiler, Testfiles für E2E-Tests, JUnit-Tests für E2E-Tests mit Reflections, Negative Testfiles und Überprüfung, ob sie bei Kompilierung Fehler werfen, Dokumentation

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 Typecheck:

  • Die Testfiles (.java), die alle Features abdecken, sind im Ordner src/test/testFiles/ASTandTypedASTFeatures zu finden. Der Name des jeweiligen Files gibt circa an, welches Feature / welche Features es abdeckt.
  • Ihre manuell übersetzten ASTs befinden sich im Ordner src/test/java/ScannerParserTests/FeaturesASTs
  • Die Übereinstimmung der manuell übersetzten ASTs mit den vom Compiler generierten ASTs wird mit JUnit-Tests im File src/test/java/ScannerParserTests/ScannerParserTests.java überprüft
  • Die manuell übersetzten TypedASTs befinden sich im Ordner src/test/java/TypeCheckTests/FeaturesTypedASTs
  • Die Übereinstimmung der manuell übersetzten TypedASTs mit den vom Compiler generierten TypedASTs wird mit JUnit-Tests im File src/test/java/TypeCheckTests/TypingTests.java überprüft
  • 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/ScannerParserTests/MoreTestsASTs und src/test/java/TypeCheckTests/MoreTestsTypedASTs zu finden. Die korrekte Umwandlung der Testfiles in AST und TypedAST wird in den gleichen Testklassen wie die Features getestet.

Tests für den gesamten Compiler:

  • Da die Kompilierung der Testfiles für den Scanner, Parser und Typecheck 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 einem Objekt der Klasse auslesen und zurückgeben. Diese Werte werden dann mit den erwarteten Werten in der jeweiligen Testklasse verglichen.

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 sind 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. Die Testfiles, die in keine Kategorie passen werden in der Testklasse src/test/java/NegativeTests/RestOfNegativeTests.java getestet
  • Hinweis: Bitte die Ausgabe in der Konsole ignorieren, diese Fehlermeldungen sind die erwarteten Fehlermeldungen, die der Compiler ausgeben soll, werden in diesem Test-Fall jedoch nicht unterdrückt.