split out vm-specific tests

split out vm-specific tests

These two tests check for arbitrary precision integers and 4-byte unicode support.  These features are part of the dart specification, but we have currently decided that they are not expected to be supported by a JS implementation of the language.  This change keeps the general parts of these tests - but it splits out the features a JS implementation is not expected to support into their own tests so that they can be tracked separately.

[jimhug, 2012-01-09 16:18:31]

I'd prefer to commit this change using these test names that match the
established conventions in the test suite.  I'd be more than happy if someone
wants to take on the task of refactoring both these new tests and all existing
ones to some different naming convention.

[jimhug, 2012-01-11 17:57:50]

Hi ivan,

I've tried to accurately separate these two tests into parts that should work
with the JS exemption and parts that are required for full dart spec compliance.
 I've also tried to capture this purpose in the comments as we discussed this
morning.

Can you or someone else on the VM team please give this a careful review to
ensure that I haven't changed the intent of the tests while trying to do this
separation?

Thanks - Jim

[Ivan Posva, 2012-01-13 00:54:25]

Adding Kasper for questions relating to the JS exemption.

-Ivan

http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
File tests/language/src/BitOperationsTest.dart (right):

http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
tests/language/src/BitOperationsTest.dart:23: Expect.equals(0x10000000, 1 <<
28);
Isn't the range representable in bit operations in JS 32-bits?

http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
tests/language/src/BitOperationsTest.dart:73: Expect.equals(0, 0 >> 30);
Not sure about this. Does the JS exemption also redefine the masking behaviour
of the shift operation? If not then these tests should likely not be impacted.

[kasperl, 2012-01-16 08:37:32]

Thanks for looping me in. I'll discuss how we can start documenting the JS
numeric exemption better with Gilad later today.

http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
File tests/language/src/BitOperationsTest.dart (right):

http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
tests/language/src/BitOperationsTest.dart:73: Expect.equals(0, 0 >> 30);
On 2012/01/13 00:54:25, Ivan Posva wrote:
> Not sure about this. Does the JS exemption also redefine the masking behaviour
> of the shift operation? If not then these tests should likely not be impacted.

This is an interesting question. We clearly need to specify the JS numeric
exemption better. It might be nice to extend this file with a test case that
shows that the current 'expected' behavior when compiled to JS is to mask the
shift count -- e.g. let (4 >> 33) == 2. Maybe we should change the name of this
method accordingly?

[Ivan Posva, 2012-06-25 23:24:34]

On 2012/01/16 08:37:32, kasperl wrote:
> Thanks for looping me in. I'll discuss how we can start documenting the JS
> numeric exemption better with Gilad later today.
> 
>
http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
> File tests/language/src/BitOperationsTest.dart (right):
> 
>
http://codereview.chromium.org/9149005/diff/6001/tests/language/src/BitOperat...
> tests/language/src/BitOperationsTest.dart:73: Expect.equals(0, 0 >> 30);
> On 2012/01/13 00:54:25, Ivan Posva wrote:
> > Not sure about this. Does the JS exemption also redefine the masking
behaviour
> > of the shift operation? If not then these tests should likely not be
impacted.
> 
> This is an interesting question. We clearly need to specify the JS numeric
> exemption better. It might be nice to extend this file with a test case that
> shows that the current 'expected' behavior when compiled to JS is to mask the
> shift count -- e.g. let (4 >> 33) == 2. Maybe we should change the name of
this
> method accordingly?

Closing this review: Obsolete.