[
https://issues.apache.org/jira/browse/GROOVY-12560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134400#comment-18134400
]
ASF GitHub Bot commented on GROOVY-12560:
-----------------------------------------
codeconsole opened a new pull request, #3088:
URL: https://github.com/apache/groovy/pull/3088
Under `@CompileStatic`, `a <=> b` called the compare method of the wrapper
of the left operand's type whenever the right operand had a primitive type, not
only when both had the same primitive type: the condition read "same type and
primitive left, or primitive right".
```groovy
@CompileStatic
class C {
static int wide(int x, long y) { x <=> y } // 0 <=> 4294967296L gave 0
static int frac(int x, double y) { x <=> y } // 1 <=> 1.5d gave 0
static int nul(Integer x, int y) { x <=> y } // null <=> 1 threw
NullPointerException
}
```
A left operand of a type without a compare method, such as `BigDecimal`, a
type parameter or `Number`, crashed the compiler with an
IndexOutOfBoundsException, which also hit `a <=> b >= 0` (it parses as `a <=>
(b >= 0)`). Only operands of the same primitive type now use the wrapper's
compare method; any other pair is compared as in dynamic Groovy.
## Tests
`STCnAryExpressionTest.testSpaceshipOperatorWithPrimitiveRightOperand`, also
run statically compiled, fails without the change. 11,626 tests in the
`groovy`, `gls`, `bugs` and STC/SC packages pass, apart from a `@Grab` test
that passes on rerun. The Checkstyle and CodeNarc gates pass.
Seen in 4.0.33, 5.0.8 and 6.0.0.
> SC: <=> with operands of different types narrows the right operand, unboxes a
> null left operand or crashes the compiler
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12560
> URL: https://issues.apache.org/jira/browse/GROOVY-12560
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> Under {{@CompileStatic}}, {{a <=> b}} calls the compare method of the wrapper
> of the left operand's type whenever the right operand has a primitive type,
> not only when both operands have the same primitive type:
> {code:groovy}
> @groovy.transform.CompileStatic
> class C {
> static int wide(int x, long y) { x <=> y }
> static int frac(int x, double y) { x <=> y }
> static int nul(Integer x, int y) { x <=> y }
> }
> assert C.wide(0, 4294967296L) == -1 // 0
> assert C.frac(1, 1.5d) == -1 // 0
> assert C.nul(null, 1) == -1 // NullPointerException
> {code}
> When the left operand's type has no such compare method, such as
> {{BigDecimal}}, a type parameter or {{Number}}, the compiler crashes:
> {code:groovy}
> @groovy.transform.CompileStatic
> int cmp(BigDecimal x, int y) { x <=> y }
> // General error during canonicalization: Index 0 out of bounds for length 0
> {code}
> This also hits {{a <=> b >= 0}}, which parses as {{a <=> (b >= 0)}}. Dynamic
> Groovy and {{@TypeChecked}} give -1 in all three cases.
> Expected: only operands of the same primitive type use the wrapper's compare
> method; any other pair is compared as in dynamic Groovy.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
