another weird parser case

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

another weird parser case

ocs@ocs
Hi there,

lately, I got bit in my tender parts by this catch, sorta similar to the debate of the more-line-expression of late -- this time, though, a line which I presumed to be compiled separately is considered a part of the previous command:

===
20 /tmp> <q.groovy
class foo {
  static bar() { }
  static Closure baz() {
    bar()// ';' here mandatory, or a return on the next line
    { -> }
  }
}
foo.baz()
21 /tmp> /usr/local/groovy-3.0.0-alpha-3/bin/groovy q
Caught: groovy.lang.MissingMethodException: No signature of method: static foo.bar() is applicable for argument types: (foo$_baz_closure1) values: [foo$_baz_closure1@ae7950d]
...
===

I am not sure whether it can be fixed without breaking other functionalities (perhaps not; note e.g., that a 'bar(Closure)' could be added through a metaclass dynamically before the call); and even if it could, whether it would be worth the effort.

All the best,
OC