Java Compiler Exception in RascalMPL while parsing

[Ejehi]

I encountered this exception while parsing my grammar in rascal:

|std:///ParseTree.rsc|(16210,1501,<405,0>,<426,141>): Java(
  "JavaCompilation",
  "Java compilation failed due to code too large",
  Java("JavaCompilerException","Compilation failed."))
        at org.rascalmpl.interpreter.utils.JavaBridge.compileJava(|unknown:///JavaBridge.java|(0,0,<134,0>,<134,0>))
        at org.rascalmpl.interpreter.utils.JavaBridge.compileJava(|unknown:///JavaBridge.java|(0,0,<113,0>,<113,0>))
        at org.rascalmpl.parser.ParserGenerator.getNewParser(|unknown:///ParserGenerator.java|(0,0,<245,0>,<245,0>))
        at org.rascalmpl.parser.ParserGenerator.getNewParser(|unknown:///ParserGenerator.java|(0,0,<207,0>,<207,0>))
        at org.rascalmpl.values.RascalFunctionValueFactory.generateParser(|unknown:///RascalFunctionValueFactory.java|(0,0,<108,0>,<108,0>))
        at org.rascalmpl.values.RascalFunctionValueFactory.lambda$new$0(|unknown:///RascalFunctionValueFactory.java|(0,0,<85,0>,<85,0>))
        at com.github.benmanes.caffeine.cache.LocalLoadingCache.lambda$newMappingFunction$3(|unknown:///LocalLoadingCache.java|(0,0,<197,0>,<197,0>))
        at com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(|unknown:///BoundedLocalCache.java|(0,0,<2550,0>,<2550,0>))
        at java.util.concurrent.ConcurrentHashMap.compute(|unknown:///ConcurrentHashMap.java|(0,0,<1916,0>,<1916,0>))
        at com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(|unknown:///BoundedLocalCache.java|(0,0,<2548,0>,<2548,0>))
        at com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(|unknown:///BoundedLocalCache.java|(0,0,<2531,0>,<2531,0>))
        at com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(|unknown:///LocalCache.java|(0,0,<110,0>,<110,0>))
        at com.github.benmanes.caffeine.cache.LocalLoadingCache.get(|unknown:///LocalLoadingCache.java|(0,0,<58,0>,<58,0>))
        at org.rascalmpl.values.RascalFunctionValueFactory.getParserClass(|unknown:///RascalFunctionValueFactory.java|(0,0,<116,0>,<116,0>))
        at org.rascalmpl.values.RascalFunctionValueFactory.parser(|unknown:///RascalFunctionValueFactory.java|(0,0,<229,0>,<229,0>))
        at org.rascalmpl.library.Prelude.parser(|unknown:///Prelude.java|(0,0,<2347,0>,<2347,0>))
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(|unknown:///NativeMethodAccessorImpl.java|(0,0,<0,0>,<0,0>))
        at parser(|std:///ParseTree.rsc|(16184,7,<402,88>,<402,95>))
        at $shell$(|prompt:///|(0,36,<1,0>,<1,36>)ok

I have provided a link to the project below:

https://github.com/Ejehi/rascal-snowflake/blob/main/snowflake/src/grammar/SnowFlake.rsc#L6

Context: VSCode Rascal Version: 0.34.1

[DavyLandman]

So I'll let @jurgenvinju diagnose this. But looking at the grammar: https://github.com/Ejehi/rascal-snowflake/blob/main/snowflake/src/grammar/DDL.rsc it's a very verbose and big grammar. Rascal grammars tend to offer ways of making it more compact.

Maybe review the options here: https://www.rascal-mpl.org/docs/Rascal/Declarations/SyntaxDefinition/

For inspiration, check out the grammars in this module: https://github.com/usethesource/rascal/tree/main/src/org/rascalmpl/library/lang

I'm curious, did you write this impressive grammar by hand, or generate out if an existing specification?

[DavyLandman]

Ow, and here is a sql "like" language we developed a while back: https://github.com/typhon-project/typhonql/blob/master/typhonql/src/lang/typhonql/DML.rsc That might also give some inspiration how to refactor the grammar a bit.

[jurgenvinju]

Ah.. that's always a bad one. "code too large" is when a class, nested class or method becomes so large that the amount of bytes allowed by the JVM is exceeded. Usually, grammar factoring can remove this problem.

If you would inline all the "singleton" rules, like these:

syntax TaskSchedule = taskSchedule: 'SCHEDULE' "=" String;

syntax TaskOverlap = taskOverlap: 'ALLOW_OVERLAPPING_EXECUTION' "=" Boolean;

into their parents, that might help. Warning: we might also run into the next limit (this is a very big grammar!) and then we'll have to see what the next step is.

[Ejehi]

Thank you for your reply. I generated the grammar out of an existing antlr specification for the snowflake database.

So I'll let @jurgenvinju diagnose this. But looking at the grammar: https://github.com/Ejehi/rascal-snowflake/blob/main/snowflake/src/grammar/DDL.rsc it's a very verbose and big grammar. Rascal grammars tend to offer ways of making it more compact.

Maybe review the options here: https://www.rascal-mpl.org/docs/Rascal/Declarations/SyntaxDefinition/

For inspiration, check out the grammars in this module: https://github.com/usethesource/rascal/tree/main/src/org/rascalmpl/library/lang

I'm curious, did you write this impressive grammar by hand, or generate out if an existing specification?

[Ejehi]

Thanks, I'll check this out

Ow, and here is a sql "like" language we developed a while back: https://github.com/typhon-project/typhonql/blob/master/typhonql/src/lang/typhonql/DML.rsc That might also give some inspiration how to factor out the grammar a bit.

[Ejehi]

Thank you for your reply. I will try this👍🏽

Ah.. that's always a bad one. "code too large" is when a class, nested class or method becomes so large that the amount of bytes allowed by the JVM is exceeded. Usually, grammar factoring can remove this problem.

If you would inline all the "singleton" rules, like these:

syntax TaskSchedule = taskSchedule: 'SCHEDULE' "=" String;

syntax TaskOverlap = taskOverlap: 'ALLOW_OVERLAPPING_EXECUTION' "=" Boolean;

into their parents, that might help. Warning: we might also run into the next limit (this is a very big grammar!) and then we'll have to see what the next step is.

[Ejehi]

Thank you @jurgenvinju

I have fixed the bug. This was really helpful in resolving the error.

Ah.. that's always a bad one. "code too large" is when a class, nested class or method becomes so large that the amount of bytes allowed by the JVM is exceeded. Usually, grammar factoring can remove this problem.

If you would inline all the "singleton" rules, like these:

syntax TaskSchedule = taskSchedule: 'SCHEDULE' "=" String;

syntax TaskOverlap = taskOverlap: 'ALLOW_OVERLAPPING_EXECUTION' "=" Boolean;

into their parents, that might help. Warning: we might also run into the next limit (this is a very big grammar!) and then we'll have to see what the next step is.