Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-JSR-1
-
Component/s: None
-
Labels:None
-
Environment:mac os x 10.3.3, java 1.4.2
Description
This bug had me scratching my head for a looong time. Here is a sample class that this happens:
Class Bug5 {
static void main(args) {
println "hello"
}
}
The error I get is:
Caught: Bug5.groovy: 2: could not use 'static' at 2:5
Bug5.groovy: 2: could not use 'static' at 2:5
Bug5.groovy: 5: could not use '}' at 5:1
at org.codehaus.groovy.control.ProcessingUnit.fail(ProcessingUnit.java:466)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:877)
at org.codehaus.groovy.control.CompilationUnit.parse(CompilationUnit.java:508)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:470)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:228)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:154)
at groovy.lang.GroovyShell$2.run(GroovyShell.java:207)
(etc)
For the sharp-eyed people, you will notice that instead of "class" I errantly did "Class". So I guess the parser is trying to declare a variable named Bug5 of type Class, but I don't understand why it allows the chunk of code in the braces. I thought valid variable declarations looked like this:
[<type>] <name> [= <value>]
Anyway, if this is valid syntax, may I request that the error message be a little more descriptive, like "static is not allowed in a field initialization block" or something like that? That would have at least clued me into that the parser thinks he's doing something different than what I was intending to do, and make my debugging a little quicker.
Thanks!
Activity
I agree with Chris here. There is a reason C-like languages require '()' in constructions like 'if 
{y}'. It firms up the syntax and prevents the parser from wandering. With Ruby-like calls in the mix, Groovy needs this convention even more.
(BTW, in other, simpler cases, I hope parentheses can be optional.)
{y}'. It firms up the syntax and prevents the parser from wandering. With Ruby-like calls in the mix, Groovy needs this convention even more.
(BTW, in other, simpler cases, I hope parentheses can be optional.)
The problem is actually that Class Bug5 is interpreted as:
Class( Bug5() { ... } )
This is why the error message is bad. For now, you can check in groovysh – the "explain" command will show you how the code is being parsed. Unfortunately, it won't (can't) show you the parse tree for code that won't parse, but you could try reducing the text a bit until you get something of the same form that can.
This is probably another reason paren need to be required.