Björn Kautler created GROOVY-11822:
--------------------------------------

             Summary: metadata methods on static nested class fail compilation 
if extended class uses slightly different signature
                 Key: GROOVY-11822
                 URL: https://issues.apache.org/jira/browse/GROOVY-11822
             Project: Groovy
          Issue Type: Bug
    Affects Versions: 4.0.29
            Reporter: Björn Kautler


Given the [following 
code|https://groovyconsole.dev/?g=groovy_4_0&codez=eNqNjUsKwkAQRPdzit5FQRvdSUAILswBPEFnbONgTA_d46CE3N34WYuL2hSvXlW1UjPL1N0YtlCItkiR_JmxVZH8wJabcsrSovhLucEVrosFJKXeQgr5tTpRZzx31b8qL8o_TeEaRRNMLL5vsebmENk75zsyg70IDA7AEqXg4VPuSIHvifujwZeHAUY3PgEE2Exx]:
{code:groovy}@Grab(value = 'org.apache.groovy.geb:geb-spock:8.0.1', transitive 
= false)
@Grab(value = 'org.apache.groovy.geb:geb-core:8.0.1', transitive = false)
import geb.spock.GebSpec

class Foo {
  static class Bar extends GebSpec { }
}{code}

If you try to compile it, you get a compiler error
{quote}The return type of void propertyMissing(java.lang.String, 
java.lang.Object) in Foo$Bar is incompatible with java.lang.Object in 
geb.spock.GebSpec{quote}

The reason is, that the extended class has a {{propertyMissing}} setter with 
`Object` return type instead of `void`.
This is perfectly fine as far as the metaprogramming functionality is concerned 
and works as intended.
But the Groovy compiler tries to generate a `void` version for the static 
nested class and then fails as only the return type of the signature is 
different which cannot work.

If you would have such metaprogramming methods directly in your code, the 
compiler would fail with a meaningful error telling that you must not use those 
methods on static inner classes which is sad but at least clear.

So maybe supertypes should be checked for the exact signature used and then the 
same signature should be used to not get a compile error due to return types of 
methods you are not involved in directly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to