issue 12062 - don't box primitives for some simple cases [ci: last-only]#9102
issue 12062 - don't box primitives for some simple cases [ci: last-only]#9102lrytz merged 1 commit intoscala:2.12.xfrom
Conversation
|
/rebuild |
3d98160 to
3cefe5b
Compare
3cefe5b to
2adaaaa
Compare
2adaaaa to
cb984e9
Compare
|
IMO it's worrying that we are now solving an issue with more code in the compiler where a 100% library-based solution would have done the job, and more reliably so: Of course, there's the binary compatibility problem now, but still... |
Wouldn't work, see scala/bug#12062:
|
6816027 to
1dc4ff5
Compare
| //new Predef.float2Float(x).intValue() -> x.toInt() | ||
| //new Predef.float2Float(x).longValue() -> x.toLong() | ||
| //new Predef.float2Float(x).floatValue() -> x.toFloat() | ||
| //new Predef.float2Float(x).doubleValue() -> x.toDouble() |
There was a problem hiding this comment.
Should we handle conversions from the other primitive types? 1.longValue has the same issue, it compiles to int2Integer(1).longValue (boxes), not intWrapper(1).longValue (doesn't box).
On the other hand, is it worth handling these conversions? Are people actually using xValue instead of toX?
There was a problem hiding this comment.
seems easy enough to do. will squash and add this on top to review
66790c5 to
2a3485a
Compare
|
@lrytz squashed and updated with your comments |
8bb6c40 to
2d0b76a
Compare
66af97e to
af5e717
Compare
af5e717 to
02be333
Compare
02be333 to
0bf5409
Compare
fb3dafe to
7d04b06
Compare
2a13c63 to
5ad8df9
Compare
|
(rebased on current 2.12.x) |
lrytz
left a comment
There was a problem hiding this comment.
LGTM. Pushed a tiny cleanup. We should squash everything before merging.
…/Float/Integer etc don't box primitives to call hashCode/toString copy with trees with side effect add tests to verify no boxing
45fd3ae to
95f0ba0
Compare
undo the wrapping of Predef.double2Double(d).isNaN() to java.lang.Double.isNaN
undo the wrapping of Predef.float2float(f).isNaN() to java.lang.Float.isNaN
do the same for other similar methods
toStringandhashCodeallocation tests are not great for boxing checks for example in Boolean, but it seemed the simplest way to check for the common cases
fixes scala/bug#12062