tree 6e8342c77b51c92a9d7eaf1a9ab1354fbdf80c8f
parent 9b15bac4b50d29b45378d83355394cef57b12e4e
author adonovan <adonovan@google.com> 1601492608 -0700
committer Copybara-Service <copybara-worker@google.com> 1601492681 -0700

BEGIN_PUBLIC
starlark: infinite precision ints

BEWARE: j.l.Integer is no longer a legal Starlark value.

This change makes the Starlark 'int' type a bigint,
aka infinite-precision integer, one capable of exact arithmetic
on any integer value. The new Int class has three subclasses,
similar to j.l.Integer, j.l.Long, and j.l.BigInteger.
The most compact representation is always used.

This makes Starlark capable of handling all the integer
types that occur in protocol messages---signed and unsigned
64-bit values.

Memory usage should not change much because StarlarkInt.Int32
has the same layout as the j.l.Integer it replaces.
As with j.l.Integer, small values (<100,000) are cached
to avoid unnecessary allocation.

Integer is no longer a legal Starlark value type. However,
for compatibility and convenience, parameters of
StarlarkMethod-annotated Java functions may continue to
use Integer to mean "32-bit signed int". The interpreter
does a "reboxing" operation to convert Int arguments
to Integer parameters as needed. Also, such functions may
return Integer values, and they will be reboxed by fromJava,
similar to List and Map. However, just as one cannot return
List and Map values nested inside Starlark data structures,
nor can one nest Integers in them; an explicit boxing operation
is required: StarlarkInt.of(x).

To limit the scope of this change, it does not yet add support
for parsing bigint literals. That will come in a follow-up.

Bazel: attr.int(..) rule attributes now use Int instead of
Integer. This is necessary because the assumption that Attribute
values are all legal Starlark values seems to be widely relied on.
However, int attributes remain restricted to the signed 32-bit
part of the value range. (Changing this would have much greater
ramifications for Bazel.) Every access of an int-valued rule
attribute must now call toIntUnchecked(), which cannot fail.

Suggested reading order:
- eval.StarlarkInt, the new type.
- the rest of eval, which does reboxing.
- trivial updates to tests of the interpreter.
  (Most of these tests belong in testdata/*.star files.)
- lib.packages attribute changes.
- the rest, which is mostly trivial updates.

The most obvious downsides of this change are the loss of implicit
boxing, the potential for latent errors due to the lack of dynamic
checkValid calls in (e.g.) Dict.put, and the need to tell other Java
packages (such as the Gson JSON package) that Int is basically a
version of Integer, which it already knows about.

I have no doubt missed a few spots, and we may encounter a few
unhelpful "want int, got int" errors when an Integer value
sneaks into the Starlark value realm. I will fix them as they
arise.

Credit to Jon Brandvein for b/36358845#comment9. Before it, I
had resigned myself to this feature being infeasible in Starlark/Java.

END_PUBLIC

PiperOrigin-RevId: 334649352