Tracking issue for platform specific integer literals

[leafpetersen]

This is the meta-issue for platform specific integer literals. See #33160 for background discussion.

The decided upon course of action is here: #33160 (comment) (also summarized below).

TODO:
Step 1: (For Dart 2 release):

• Update informal specification: Update informal specification for 64 bit integers to include platform specific literals #33283
• Update formal specification: Update Dart spec for 64 bit integers, including platform specific literals #33284
• kernel: verify correct constant evaluation: Kernel const evaluation must use platform integers #33285
• dart2js: issue an error if an integer literal cannot be exactly represented as a double: dart2js should issue an error if an integer literal cannot be represented exactly as a double #33286
• ddc: issue an error if an integer literal cannot be exactly represented as a double: ddc should issue an error if an integer literal cannot be exactly represented as a double #33287

Step 2: (Post Dart 2):

• kernel: allow all integer literals which can be exactly represented as a double when compiling for a JS platform
• kernel: emit errors for literals which cannot be exactly represented using the platform integer
• analyzer: allow all integer literals which can be exactly represented as a double when compiling for a JS platform
• analyzer: emit errors for literals which cannot be exactly represented using the platform integer
• analyzer: lint for cross platform integer literals

[leafpetersen]

More details, copied over from #33160 (comment) .

Step 1 - In the Dart 2 timeframe:

• It is an error if a literal is not exactly representable in 64 bits (current errors and warning)
• Literals are interpreted as platform numbers (option 2 above)
  • So for example 0xffffffff00000000 will denote a different value on different platforms.
• dart2js and DDC will report errors if a literal cannot be represented exactly in JS

Step 2 - In the post Dart 2 timeframe:

• It is an error if a literal is not exactly representable in 64 bits when compiling to native
• It is an error if a literal is not exactly representable as a double when compiling to JS
• It may be desirable to have an opt-in int to warn if any literal is not in the intersection of the two

An implication of all of this is that we have (more) platform specific errors and warnings. In the short term, these will only be surfaced by the compilers. The analyzer/IDE may or may not choose to offer a way to select a platform for additional errors and warnings.

Implementation implications:

Step 1:

• Requires no further work from kernel, except to guarantee that it does no incorrect-for-the-platform constant folding (which it already must guarantee)
• Requires no further work from the analyzer (modulo existing bugs in platform correct constant evaluation)
• Requires DDC and dart2js to warn if a literal is not exactly representable in JS

Step 2:

• Requires kernel to support literals that cannot be represented as 64 bit integers (at least when compiling to JS)
• Requires the analyzer/IDE to either stop warning on literals that exceed 64 bits, or else provide a platform selection mechanism to allow the correct set of errors and warnings to be surfaced.

[leafpetersen]

cc @lrhn

[dgrove]

Because this will not be complete for Dart2Stable, dropping the milestone (all sub-issues needed for Dart2Stable are marked for the Dart2Stable milestone)

[srawlins]

There should be a step to announce this breaking change as well.