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.