Ich dachte wir hatten sichergestellt, dass der Compiler nicht explodiert, wenn ein ungünstiges EOF erreicht wird.

Aber ein lookahead über mehrere Zeichen (an einer new-array-expression) führt zu einer unhandled exception:

Eingabe:

class A {
    public static void main(String[] args) {
        int a = new int

Internal error: tried to peek past the end of the sequence
java.lang.IllegalStateException: tried to peek past the end of the sequence
	at edu.kit.compiler.parser.LookaheadBuffer.peek(LookaheadBuffer.kt:43)
	at edu.kit.compiler.parser.AbstractParser.peek(AbstractParser.kt:45)
	at edu.kit.compiler.parser.AbstractParser.peek$default(AbstractParser.kt:45)
	at edu.kit.compiler.parser.Parser.parseUnaryExpression-7yDSdB4(Parser.kt:366)
	at edu.kit.compiler.parser.Parser.parseExpression-Qkhz27U$compiler(Parser.kt:395)
	at edu.kit.compiler.parser.Parser.parseExpression-Qkhz27U$compiler$default(Parser.kt:391)
	at edu.kit.compiler.parser.Parser.parseNewArrayExpression-7yDSdB4(Parser.kt:201)
	at edu.kit.compiler.parser.Parser.parseNewObjectArrayExpression-7yDSdB4(Parser.kt:136)
	at edu.kit.compiler.parser.Parser.parsePrimaryExpression-7yDSdB4(Parser.kt:106)
	at edu.kit.compiler.parser.Parser.parsePostfixExpression-7yDSdB4(Parser.kt:263)
	at edu.kit.compiler.parser.Parser.parseUnaryExpression-7yDSdB4(Parser.kt:387)
	at edu.kit.compiler.parser.Parser.parseExpression-Qkhz27U$compiler(Parser.kt:395)
	at edu.kit.compiler.parser.Parser.parseExpression-Qkhz27U$compiler$default(Parser.kt:391)
	at edu.kit.compiler.parser.Parser.parseLocalVariableDeclarationStatement-7yDSdB4(Parser.kt:1103)
	at edu.kit.compiler.parser.Parser.parseBlockStatement-7yDSdB4(Parser.kt:865)
	at edu.kit.compiler.parser.Parser.parseBlockStatements(Parser.kt:841)
	at edu.kit.compiler.parser.Parser.parseBlock-7yDSdB4$compiler(Parser.kt:813)
	at edu.kit.compiler.parser.Parser.parseMainMethod-7yDSdB4(Parser.kt:659)
	at edu.kit.compiler.parser.Parser.parseClassMember-7yDSdB4(Parser.kt:536)
	at edu.kit.compiler.parser.Parser.parseClassMembers-7yDSdB4(Parser.kt:486)
	at edu.kit.compiler.parser.Parser.parseClassDeclarations-7yDSdB4$compiler(Parser.kt:460)
	at edu.kit.compiler.parser.Parser.parse(Parser.kt:38)
	at edu.kit.compiler.Compiler.compile(Compiler.kt:82)
	at edu.kit.compiler.Cli.run(Main.kt:26)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:198)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:18)
	at com.github.ajalt.clikt.core.CliktCommand.parse(CliktCommand.kt:395)
	at com.github.ajalt.clikt.core.CliktCommand.parse$default(CliktCommand.kt:392)
	at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:410)
	at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:435)
	at edu.kit.compiler.MainKt.main(Main.kt:30)

Process finished with exit code 127

• [x] nimmt 01 als syntaktisch korrekten Ausdruck an und behält nur 0
• [x] nicht-statische Methode main kann nicht aufgerufen werden
• [x] System.out.println(new A().bla(new A()));, bla gibt A zurück
• [x] Fehlermeldung von System.out.println(new A()) gibt unformatierte Compiler-Objekte aus

Es gibt gefühlt 300 verschiedene Funktionen um etwas am AST zu checken und im Fehlerfall nen Error auszugeben. Die könnte man mal alle in eine elegante Lösung vereinigen.

Auch sonstige Utilities kann man dabei mal auf Redundanz checken.

Wenn der Parser eine Unterscheidung durch Lookahead macht, und im else Teil nicht failt sondern einen rekursiven Abstieg macht, dann wird er nach dem Abstieg bei einem illegalen Token falsche Annahmen bezüglich der Recovery treffen. Illegale Tokens müssen vor dem Abstieg gelesen werden:

Theoretisches Beispiel:

when(val p = peek()) {
    case LBRACE -> parseArrayAccess(anc)
    case LPAREN -> parseMethodCall(anc)
    else -> parseStatement(anc)
}

wird bei einem Input von ident!(...) (mit ident gerade gelesen, also peek() == '!' in parseStatement absteigen. Dann wird in parseStatement erkannt dass ! illegal ist, aber dennoch ins Statement parsing recovered, obwohl danach das vorher nicht betrachtete ( steht.

Jetzt wo der Parser wiederaufsetzen kann, muss der AST noch fehlertolerant konstruiert werden, (sodass der Parser nicht trotz Wiederaufsetzen abstürzen muss).

Ich habe Lenient.Error abgeändert und schreibe keine Fehlermeldungen mehr hinein, weil die ohnehin nur im SourceFile benötigt und verwertet werden, und es den Code übersichtlicher machen sollte, wenn ich die da direkt hinschreibe. Vorrangig muss jedoch der AST noch weiter verändert werden, und Parserfunktionen so abgeändert, dass sie Nodes als invalid kennzeichnen, wenn Parserfehler entstehen (auch wenn alle notwendigen Informationen zum Parsing theoretisch vorliegen).

Der Branch baut nicht, weil ich die expect-Funktionen so abgeändert habe, dass sie auch Optional.empty() zurückgeben können, wenn ein erwartetes Token nicht da ist.

(hopefully) correct processing of files with

• nice error handling
• buffered character-based loading-
• asynchronous loading of data
• correct handling of character devices
• correct encoding
• look-ahead capabilities

Joa, wir sollten wohl noch irgendeine Form von junit aufsetzen, für ein paar Unit-Tests. Optional mit tollem Github Workflow für automatisierte Tests beim Merge/Commit auf den Master-Branch.

Sollen wir auch versuchen irgendwelche externen Integration-Tests aufzusetzen?

Apparently, gradle 7.1 doesn't support JDK 17, which is installed in our Speedcenter. That's probably why your build seems to fail consistently with "Unsupported class file major version 61": http://speedcenter.informatik.kit.edu/compprakt/run-detail/ff5e36b7-d470-40ea-adb0-5d28a4497ec1

• #76
• #101
• Codeerzeugung
  • [x] Zwischensprache(n?): für molki @iTob191
  • [x] SSA-Abbau (wann?)
  • [x] #109
  • [x] Befehlsanordnung
  • [x] Register-"Allokation" @Cydhra

Weil wir Feldzugriffe immer als Lesezugriff werten, wenn sie nicht in einer Assignment Expression stehen, wird eine FieldAccessExpression als target einer ArrayAccessExpression immer als Lesezugriff verstanden, obwohl sie teil eines Schreibzugriffs sein sollte.

Auf feature/type_analysis ham wir den MJ-Tests-Stand aktualisiert, um die semantic tests zu bekommen und da ist ein Test dabei, der fehlschlägt: OpeningComment.invalid.mj

Muss man sich irgendwann mal anschauen.

• [x] Konstantenfaltung #97
• [ ] Triviale Phi-Funktionen entfernen
• [ ] Unnötige Blöcke entfernen
• [x] Mathematische Äquivalenzen @iTob191
• [ ] Common Subexpression Elimination
• [ ] Load/Store
• [ ] (Strength Reduction)
• [ ] Loop-Invariant Code Motion
• [ ] Inlining maybe? @iTob191
• [ ] Tailrec maybe maybe? @csicar