[jira] [Commented] (GROOVY-9406) `VerifyError` when annotating with both @InheritConstructors and @NullCheck and calling the resulting c'tor

["Paul King (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039423#comment-17039423 ] 

Paul King commented on GROOVY-9406:
-----------------------------------

Good catch Christoph. Both transforms run at the {{CANONICALIZATION}} phase, so the order matters and its a given with this declarative style of programming that there can be transform interactions.
If {{NullCheck}} is first, it instruments all existing methods/constructors with null checks (but there aren't any at that point). Then {{InheritConstructors}} adds the required constructors.
If {{InheritConstructors}} is first, the required constructor is added which calls {{super(id)}} as the first statement (and it is required to be first). The bug is that {{NullCheck}} is adding the check for null ahead of the {{super(id)}} statement.

> `VerifyError` when annotating with both @InheritConstructors and @NullCheck and calling the resulting c'tor
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-9406
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9406
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 3.0.1
>            Reporter: Christoph Frick
>            Priority: Major
>
> Given a class annotated with both `@InheritConstructors` and
>  `@NullCheck` (note the order!), a `java.lang.VerifyError` happens, when
>  the c'tor is called.
> E.g.
> {code:groovy}
> class Base {
> 	Long id
> 	Base(Long id) { this.id = id }
> }
> @groovy.transform.InheritConstructors // <1>
> @groovy.transform.NullCheck           // <2>
> class Sub extends Base {}
> new Sub(null)
> {code}
> Results in:
> {noformat}
> Caught: java.lang.VerifyError: Bad operand type when invoking <init>
> Exception Details:
>   Location:
>     Sub.<init>(Ljava/lang/Long;)V @38: invokespecial
>   Reason:
>     Invalid type: 'Sub' (current frame, stack[0])
>   Current Frame:
>     bci: @38
>     flags: { }
>     locals: { 'Sub', 'java/lang/Long', '[Lorg/codehaus/groovy/runtime/callsite/CallSite;' }
>     stack: { 'Sub', 'java/lang/Long' }
>   Bytecode:
>     0x0000000: b800 104d 2ab7 0013 2b01 b800 1999 0014
>     0x0000010: 2c12 1a32 121c 121e b900 2403 00c0 0026
>     0x0000020: bf2a 2bc0 0028 b700 2ab1               
>   Stackmap Table:
>     full_frame(@33,{Object[#2],Object[#40],Object[#48]},{})
> java.lang.VerifyError: Bad operand type when invoking <init>
> Exception Details:
>   Location:
>     Sub.<init>(Ljava/lang/Long;)V @38: invokespecial
>   Reason:
>     Invalid type: 'Sub' (current frame, stack[0])
>   Current Frame:
>     bci: @38
>     flags: { }
>     locals: { 'Sub', 'java/lang/Long', '[Lorg/codehaus/groovy/runtime/callsite/CallSite;' }
>     stack: { 'Sub', 'java/lang/Long' }
>   Bytecode:
>     0x0000000: b800 104d 2ab7 0013 2b01 b800 1999 0014
>     0x0000010: 2c12 1a32 121c 121e b900 2403 00c0 0026
>     0x0000020: bf2a 2bc0 0028 b700 2ab1               
>   Stackmap Table:
>     full_frame(@33,{Object[#2],Object[#40],Object[#48]},{})
> 	at nullcheckinherhitctor.run(nullcheckinherhitctor.groovy:10)
> {noformat}
> Please note: switching `<1>` and `<2>` does *not* show this error, but
>  the `null` does not throw either.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)