Import the v8-i18n extension into v8

Import the v8-i18n extension into v8

This adds the gyp flag v8_enable_i18n_support (off by default), and the
v8 flag FLAG_enable_i18n (on by default, but without effect if
v8_enable_i18n_support is off).

BUG=v8:2745
R=cira@chromium.org, danno@chromium.org, jkummerow@chromium.org

Committed: http://code.google.com/p/v8/source/detail?r=15464

[jochen (gone - plz use gerrit), 2013-07-02 14:31:48]

PTAL

I'll add the unit tests tomorrow.

The next steps I plan are:

- turn on the extension for v8 standalone build
- move the extension into the v8::internal namespace
- convert from extension to built-in code, so we can snapshot it
- add snapshot support

in parallel, we can switch chrome to enabling the i18n extension and drop the
dependency on the v8-i18n project

[danno, 2013-07-03 08:39:06]

Generally, looks like the right direction as long as you do indeed execute your
long-term plan. I'll defer to Jakob for the specifics of the build changes, but
the rest LGTM.

[Nebojša Ćirić, 2013-07-03 09:23:40]

I guess next step should be disabling the extension in the WebKit code (our
Blink part) and enabling v8 implementation (this CL) for Chrome.

LGTM

https://codereview.chromium.org/18487004/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/18487004/diff/1/src/api.cc#newcode442
src/api.cc:442: i::I18NNatvies::GetScriptsSource();
i::I18NNatives (misspelled).

[Jakob Kummerow, 2013-07-03 11:21:03]

Build system changes LGTM. I've verified that by default it builds fine even
when ICU is not checked out into third_party/icu.

I'll land.

[Jakob Kummerow, 2013-07-03 11:22:50]

Committed patchset #1 manually as r15464 (presubmit successful).

[Jakob Kummerow, 2013-07-03 11:25:18]

Oops, overlooked Cira's comment. Sorry. Please fix in a follow-up CL.

[arv (Not doing code reviews), 2013-07-08 17:59:23]

This implementation leaks a lot of internal implementation details and depends
on no one changing any of the globals bindings. It should be refactored to not
touch any global builtin and only use internal functions.

https://codereview.chromium.org/18487004/diff/1/src/extensions/i18n/break-ite...
File src/extensions/i18n/break-iterator.js (right):

https://codereview.chromium.org/18487004/diff/1/src/extensions/i18n/break-ite...
src/extensions/i18n/break-iterator.js:40: if
(iterator.hasOwnProperty('__initializedIntlObject')) {
Now that this is in V8 we should not use hacks like these.

You should be able to use a private symbol or a WeakMap so we do not leak this.

https://codereview.chromium.org/18487004/diff/1/src/extensions/i18n/date-form...
File src/extensions/i18n/date-format.js (right):

https://codereview.chromium.org/18487004/diff/1/src/extensions/i18n/date-form...
src/extensions/i18n/date-format.js:101: ldmlString =
ldmlString.replace(QUOTED_STRING_RE, '');
What if replace has been overridden? Same goes for match and other methods. We
should really call the internal methods.

https://codereview.chromium.org/18487004/diff/1/src/extensions/i18n/date-form...
src/extensions/i18n/date-format.js:184: options = Object.apply(this, [options]);
Needs to be the original Object and original apply.

[jochen (gone - plz use gerrit), 2013-07-08 18:28:08]

These are all excellent points, Erik, and I intend to address this issue.

The plan is to change the code from an extension to proper v8 code, so it can
eventually be part of the snapshot. In this process, we can remove all the
hacks.

Note that this is a 1:1 copy of the v8-i18n extension which is already compiled
in by chrome, so the issues you listed already apply to our shipping product :-/