Grammar rule 'classDeclaration' error
54754N4 opened this issue · comments
Description
I litterally just copy pasted the 3 kotlin .g4 files and ran grun to check the generated AST using the MutableStack<E> code from the example here : https://play.kotlinlang.org/byExample/01_introduction/06_Generics
And it seems like it can't match the LCURLY bracket of the classBody rule ? Could anyone confirm please
Output + AST
I seem to have introduced a typo in the KotlinParser.g4 file without realizing it =v= i'm sorry for creating a useless issue
Don't worry about it
Literally any feedback for the grammar is appreciated as it shows somebody is actively using it =)
I've been messing with it for a few days now and had no issues until now hehe =p so thank you very much for this !
Although I really like the way the lexer grammar was made to handle string templates, i'm just not sure how the Inside_<token> rules work (the ones defined for the Inside mode specifically) =O since they're never referenced anywhere else in any of the grammars ?
The Inside_ rules are there to distinguish expressions inside parentheses from free-range ones. The Inside_WHATEVER: WHATEVER -> type(WHATEVER); boilerplate code maps them to their non-inside counterparts so they do not need to be referenced anywhere as the token stream will contain the non-Inside variant.
Why do we need to distinguish expressions inside parentheses? Because inside parentheses you can safely ignore newlines and you cannot do that on the top-level. An example of this is, for example, a * b:
a
* b // you cannot do this in Kotlin
(a
* b) // but you can do this!
This makes sense now, thanks for the great explanation hehe !
This is not ideal, though, because there are other contexts where skipping newlines is also allowed, but you cannot detect it during lexing, so we just don't support them in ANTLR. It is, however, nigh impossible to encounter in real code.
Yeah that's true I haven't even thought that x'] i only thought about the different contexts between template strings (where they're useless) and inside actual code (where they're important language tokens [e.g. statement separators etc])
And IMHO the way you handled them in the parsing phase with many NL* to specify where they're allowed explicitly matches the fact that they can be used as language tokens, and skipping them only in the Inside lexer mode is good enough (at least for me =p)
Edit: From the grammar, unless i missed something, you only skip/hide newlines inside parenthesis or brackets which i think is perfectly fine for kotlin, but then again my knowledge is limited haha