# 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


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