[
https://issues.apache.org/jira/browse/GROOVY-12471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131976#comment-18131976
]
ASF GitHub Bot commented on GROOVY-12471:
-----------------------------------------
paulk-asert commented on PR #3007:
URL: https://github.com/apache/groovy/pull/3007#issuecomment-6405311480
Thanks Daniel. Answers to your points, all checked against a local build of
this head:
- Bridge: Bridger turns abs$$bridge into abs(Number)I flagged
ACC_BRIDGE|ACC_SYNTHETIC. A Java class and a @CompileStatic class compiled
against 6.0.0-beta-2 run unchanged on the new jar, still with the old
truncating result as intended for legacy callers. Same pattern as the existing
chop$$bridge and findIndexValues$$bridge. The bridge name is not visible to
dynamic dispatch.
- Static selection: Integer receivers resolve to abs(Integer) → int;
receivers typed as Number resolve to abs(Number) → Number.
- Long.MIN_VALUE: NumberMath.abs delegates to Math.abs(long), so
Long.MIN_VALUE stays Long.MIN_VALUE, identical to the existing abs(Long) and to
Java. I'll add a sentence to the javadoc.
- @since: 6.0.1, assuming backport to 6_0_X.
One side effect worth calling out. Under @CompileStatic, `int x = n.abs()`
with a Number-typed receiver is now an STC error ("Cannot assign value of type
java.lang.Number to variable of type int"), and Java callers assigning the
result to int get the equivalent javac error. For Number receivers that code
was already producing wrong values, so I think the compile error is the right
outcome.
Short and byte receivers were correct before, though, and would have fallen
into the same error since they resolve to abs(Number). I've added int
abs(Short) and int abs(Byte) overloads so those keep compiling and keep
returning int, with tests covering the static int assignment, Short.MIN_VALUE
and Byte.MIN_VALUE, and the dynamic result type. The remaining source change is
confined to receivers whose static type is Number itself. I'll note that in
COMPATIBILITY.md.
> SC: Method abs misbehaves under static compilation
> --------------------------------------------------
>
> Key: GROOVY-12471
> URL: https://issues.apache.org/jira/browse/GROOVY-12471
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.5.23, 3.0.25, 5.0.3, 4.0.33, 5.1.3, 6.0.0
> Reporter: Björn Kautler
> Assignee: Paul King
> Priority: Major
>
> The snippet
> {code:groovy}
> @groovy.transform.CompileStatic
> def delta(Number item, Number value) {
> (item - value).abs()
> }
> println delta(2.2, 3.3)
> println delta(Long.MAX_VALUE, 1)
> {code}
> produces the outputs "1" and "2" while it should be "1.1" and
> "9223372036854775806".
> I assume the problem is, that SC chooses {{DGM.abs(Number)}} which unluckily
> assumes that {{{}Long{}}}, {{{}Float{}}}, {{{}Double{}}}, {{{}BigInteger{}}},
> and {{BigDecimal}} are handled by other methods (DGM or in the type itself)
> and thus treats any input as integer or smaller and returning {{{}int{}}},
> while this assumption does not necessarily hold under static compilation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
