Change dart2js int.toRadixString to not return spurious format on IE.

Change dart2js int.toRadixString to not return spurious format on IE.

BUG= http://dartbug.com/15316
R=floitsch@google.com

Committed: https://code.google.com/p/dart/source/detail?r=42764

[floitsch, 2013-11-26 10:25:49]

LGTM.

https://codereview.chromium.org/87523003/diff/1/sdk/lib/_internal/lib/js_numb...
File sdk/lib/_internal/lib/js_number.dart (right):

https://codereview.chromium.org/87523003/diff/1/sdk/lib/_internal/lib/js_numb...
sdk/lib/_internal/lib/js_number.dart:138: // TODO(floitsch): precision must be
an integer.
Remove todo.

[ahe, 2013-11-26 11:25:46]

https://codereview.chromium.org/87523003/diff/30001/sdk/lib/_internal/lib/js_...
File sdk/lib/_internal/lib/js_number.dart (right):

https://codereview.chromium.org/87523003/diff/30001/sdk/lib/_internal/lib/js_...
sdk/lib/_internal/lib/js_number.dart:167: StringBuffer buf = new
StringBuffer(match[1]);
Please use string concatenation instead of StringBuffer. Generally,
StringBuffers add overhead, whereas browsers optimize for string concatenation.

[Lasse Reichstein Nielsen, 2013-11-26 14:01:05]

IE isn't the only browser to give spurious results in some cases. Chrome/V8 does
the wrong thing for some .toString(r)'s (e.g., 0x8000000000000800.toString(3).)

I'll hold back the CL and investigate some more.

[Lasse Reichstein Nielsen, 2013-11-27 09:33:02]

Ok, all browsers do the wrong thing on some numbers.
The ECMAScript spec allows an "implementation specific approximation" for both
toString and parseInt with radices not 10 or a power of 2. That means that we
can't implement exact int.toRadixString using JS primitives in all cases, and we
either have to consider this another artifact of dart2js, or we have to
implement an exact toRadixString for large integers manually.

[Lasse Reichstein Nielsen, 2015-01-12 09:00:03]

Committed patchset #6 (id:90001) manually as 42764 (presubmit successful).