Skip to content

SI-9516 Fix the behavior of Int shift Long operations. #5117

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 23, 2016

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Apr 22, 2016

In any shift operation where the lhs is an Int (or smaller) and
the rhs is a Long, the result kind must be Int, and not Long.
This is important because the lhs must not be promoted to a
Long, as that causes an opcode for long shift to be emitted.
This uses an rhs modulo 64, instead of int shifts which use an
rhs module 32. Instead, the rhs must be downgraded to an Int.

The new behavior is consistent with the same operations in the
Java programming language.

Link to SI-9516: https://issues.scala-lang.org/browse/SI-9516

@scala-jenkins scala-jenkins added this to the 2.12.0-M5 milestone Apr 22, 2016
@sjrd
Copy link
Member Author

sjrd commented Apr 22, 2016

Review by @lrytz

@@ -102,13 +102,13 @@ abstract class ConstantFolder {
case nme.XOR => Constant(x.longValue ^ y.longValue)
case nme.AND => Constant(x.longValue & y.longValue)
case nme.LSL if x.tag <= IntTag
=> Constant(x.intValue << y.longValue)
=> Constant(x.intValue << y.longValue.toInt) // .toInt required to bootstrap despite SI-9516
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe change this comment, something like TODO: remove .toInt once starr is includes the fix for SI-9516 (2.12.0-M5)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK Done.

@sjrd sjrd force-pushed the SI9516-int-shift-long branch from 4ae66da to 9057bf6 Compare April 22, 2016 15:45
In any shift operation where the lhs is an Int (or smaller) and
the rhs is a Long, the result kind must be Int, and not Long.
This is important because the lhs must *not* be promoted to a
Long, as that causes an opcode for long shift to be emitted.
This uses an rhs modulo 64, instead of int shifts which use an
rhs module 32. Instead, the rhs must be downgraded to an Int.

The new behavior is consistent with the same operations in the
Java programming language.
@lrytz
Copy link
Member

lrytz commented Apr 22, 2016

LGTM!

@som-snytt
Copy link
Contributor

I don't think I was paying attention in the related fix. My comment here is that the test could be junit.

@sjrd
Copy link
Member Author

sjrd commented Apr 22, 2016

@som-snytt As I explained on scala/scala-dev#136, If I make it a JUnit test, it won't succeed if run from sbt. In other words, it would break sbt test until the next starr is released.

@id-ilych
Copy link
Contributor

I don't want to seem rude but I wonder how this breaking change wasn't mentioned in 2.12 release notes?

Does complete list of behavior changes (i.e. same code compiles without a warning but gives different result) exist somewhere? Without it it seems impossible to upgrade 2.11 -> 2.12 on existing project w/o 100% tests coverage (including 3rd-party libraries).

Thanks in advance for the answer.

@lrytz lrytz added the release-notes worth highlighting in next release notes label Mar 12, 2018
@lrytz
Copy link
Member

lrytz commented Mar 12, 2018

I added the release-notes label, you're right that this PR should have it. You can check closed PRs with that label. However, you'd want to narrow down the selection to 2.12 PRs, I assume that's why we have the (kind of redundant - PRs also have a milestone assigned, but there are many 2.12 milestones..) 2.12 label. So your list would be this: https://github.com/scala/scala/pulls?q=label%3Arelease-notes+label%3A2.12+is%3Aclosed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes worth highlighting in next release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants