Surprising numeric widening in Scala - scala

Question

Code
object Test {
def main(args: Array[String]): Unit = {
val x = 123456789L
val y = 1.0F
val a = x - (if (true) { x } else { y })
val b = (if (true) { x } else { y }) - x
}
}
Result
Running this code, a is -3.0: Float and b is 0.0: Float. (x.toFloat is 1.23456792E8: Float because of precision loss.)
Scala Specification
According to Conditional Expressions and Weak Conformance: the type of the if expression in both cases is Float. (Float is the weak least upper bound of Long (the type of the then-part) and Float (the type of the else part).)
As a result, we have Long - Float in the first case, and Float - Long in the second case.
In the first case, both operands are widened (?) to Double for the calculation and the result is narrowed to Float for assignment. In the second case, both operands are widened to Float only.
According to Numeric Widening, the expected type of a must be Double for both operands to be widened to Double. However, it is Float.
What is going on here? Are any other rules at play here? Is this a bug in the compiler? Please explain in detail and cite supporting evidence. Thank you.
Bytecode
The observed behavior can be confirmed by looking at the generated bytecode:
$ javap -c 'Test$.class'
Compiled from "Test.sc"
public final class Test$ {
public static final Test$ MODULE$;
public static {};
Code:
0: new #2 // class Test$
3: invokespecial #12 // Method "<init>":()V
6: return
public void main(java.lang.String[]);
Code:
0: ldc2_w #15 // long 123456789l
3: lstore_2
4: fconst_1
5: fstore 4
7: lload_2
8: l2d
9: lload_2
10: l2f
11: f2d
12: dsub
13: d2f
14: fstore 5
16: lload_2
17: l2f
18: lload_2
19: l2f
20: fsub
21: fstore 6
23: return
}
Contrast:
l2d, followed by l2f and f2d in the first case; and l2f in the second case
dsub, followed by d2f in the first case; and fsub in the second case
Credit
https://twitter.com/aphyr/status/831200481141805056.

Answer 1

Answer
This is a bug in the Scala compiler (nsc).
I have noticed that the behavior of this program has changed in Scala v2.13.x. The old behavior is still the same in v2.12.x, up until v2.12.15. (My PR has been merged to v2.12.16.)
Old behavior: a is -3.0: Float and b is 0.0: Float.
New behavior: a is 0.0: Float and b is 0.0: Float.
Using git bisect, I've found that there was a bug report regarding the same issue. The bug was fixed in this commit, in this PR, and merged into v2.12.x branch.
Note that byte 8 l2d, and byte 11 f2d in the old bytecode are replaced by byte 8 l2f, and byte 11 fsub in the new one. Besides, byte 12 dsub and byte 13 d2f in the old one is missing in the new one.
Also note that bytes 7-12 (compute and set a) are identical to bytes 14-19 (compute and set b) (except for the destination of the fstore instructions) in the new one, as expected of the correct behavior.
Overloading Resolution for x.-(x.toFloat())
Refer to Section 6.26.3 - Overloading Resolution of the Scala Language Specification v2.12. There were some changes to the specs to support higher-order function parameter type inference in v2.13, but the rules regarding parameterized methods stay mostly the same.
val a = x - (if (true) { x } else { y }) is equivalent to val a: Float = x.-(x.toFloat());. (See section Debug below.)
Let A be the set of members referenced by e.
A = {Long#-(Double): Double, Long#-(Float): Float, Long#-(Long): Long, Long#-(Int): Long, Long#-(Char): Long, Long#-(Short): Long, Long#-(Byte): Long}
Let B be the set of alternatives in A that are applicable to expressions (e1,…,en) of types (shape(e1),…,shape(en)).
Here the expressions are (e1) of type (Nothing), hence B = A.
Otherwise, let S1,…,Sm be the list of types obtained by typing each argument as follows.
All other arguments are typed with an undefined expected type.
Here the expressions are (e1) of type (Float).
Otherwise, let CC be the set of applicable alternatives which don't employ any default argument in the application to e1,…,em.
CC = {Long#-(Float): Float (1), Long#-(Double): Double (2)}
Note that 1 is more specific than 2 because 1 is as specific as 2 but not the other way around.
Hence Long#-(Float): Float is the chosen alternative. This is comfirmed by -Ytyper-debug output. However, it doesn't state the chosen alternative explicitly.
Debug
Scala generates source code for numeric value types that doesn't contain the implementation of most methods, e.g., Long. The actual implementation, e.g., for Long#- methods, are generated at compile time. Since - is a (primitive arithmetic) binary operation, the result type of lhs - rhs is the operation type of lhs and rhs, which is computed by BTypes#maxType, which for primitive types returns the result of PrimitiveBType#maxValueType which had the bug in Scala versions prior to v2.13.x.
The code that is passed to Scala compiler (scalac -print Test.scala):
package <empty> {
object Test extends Object {
def main(args: Array[String]): Unit = {
val x: Long = 123456789L;
val y: Float = 1.0;
val a: Float = x.-(x.toFloat());
val b: Float = x.toFloat().-(x);
()
};
def <init>(): Test.type = {
Test.super.<init>();
()
}
}
}
In the old bytecode for val a: Float = x.-(x.toFloat());:
As part of genArithmeticOp(tree: Tree, code: Int):
tree = Trees.Apply(fun = Trees.Select(qualifier = "x", name = "$minus"), args = List(Trees.Apply(fun = Trees.Select(qualifier = "x", name = "toFloat"))))
code = ScalaPrimitives#SUB
larg = Trees.Select(qualifier = "x", name = "$minus")
rarg = Trees.Apply(fun = Trees.Select(qualifier = "x", name = "toFloat"))
tpeTK(larg) = BTypes.LONG
tpeTK(rarg) = BTypes.FLOAT
resKind = BTypes.LONG.maxType(BTypes.FLOAT) = BTypes.DOUBLE
As part of genLoad(larg, resKind):
byte 7 lload_2 is generated by locals.load(x)
byte 8 l2d is generated by adapt adapt(BTypes.LONG, BTypes.DOUBLE)
As part of genLoad(rarg, if (isShiftOp) INT else resKind):
As part of generatedType = genApply(app, expectedType):
expectedType = BTypes.DOUBLE
As part of genLoad(x):
byte 9 lload_2 is generated by locals.load(x)
byte 10 l2f is generated by genCoercion(ScalaPrimitives#L2F)
byte 11 f2d is generated by adapt(BTypes.FLOAT, BTypes.DOUBLE)
byte 12 dsub is generated by case SUB => bc sub resKind
byte 13 d2f is generated by adapt adapt(BTypes.DOUBLE, BTypes.FLOAT)
Bytecode
Bytecode for Scala v2.12.14 (old behavior - almost identical to that in the question):
$ javap -c 'Test$.class'
Compiled from "Test.scala"
public final class Test$ {
public static Test$ MODULE$;
public static {};
Code:
0: new #2 // class Test$
3: invokespecial #12 // Method "<init>":()V
6: return
public void main(java.lang.String[]);
Code:
0: ldc2_w #16 // long 123456789l
3: lstore_2
4: fconst_1
5: fstore 4
7: lload_2
8: l2d
9: lload_2
10: l2f
11: f2d
12: dsub
13: d2f
14: fstore 5
16: lload_2
17: l2f
18: lload_2
19: l2f
20: fsub
21: fstore 6
23: return
}
Bytecode for Scala v2.13.0 (new behavior):
$ javap -c 'Test$.class'
Compiled from "Test.scala"
public final class Test$ {
public static final Test$ MODULE$;
public static {};
Code:
0: new #2 // class Test$
3: dup
4: invokespecial #12 // Method "<init>":()V
7: putstatic #14 // Field MODULE$:LTest$;
10: return
public void main(java.lang.String[]);
Code:
0: ldc2_w #18 // long 123456789l
3: lstore_2
4: fconst_1
5: fstore 4
7: lload_2
8: l2f
9: lload_2
10: l2f
11: fsub
12: fstore 5
14: lload_2
15: l2f
16: lload_2
17: l2f
18: fsub
19: fstore 6
21: return
}