Scott Murphy Heiberg created GROOVY-12560:
---------------------------------------------
Summary: 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: 5.0.8, 4.0.33, 6.0.0
Reporter: Scott Murphy Heiberg
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)
