Implements ES6 String.prototype.normalize method.

Implements ES6 String.prototype.normalize method.

BUG=v8:2943
LOG=Y
TEST=Unit tests for "real life" use cases, edge cases, various types of normalization.

==========================

This is identical to the previous CL
   https://codereview.chromium.org/40133004/
with two differences:
 * Added a dummy implementation of String.prototype.normalize to be used when v8 is compiled without intl support
 * Rebased the the test files for webkit. That was the only reason for the previous failure (and revert).

Thank you,
Mihai

R=svenpanne@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=18972

[mnita, 2013-11-13 23:03:01]

I have rebased the webkit tests for String.prototype.normalize and added a dummy
implementation for the case when v8 is compiled without intl support.

Otherwise, nothing changed.

Thank you very much,
Mihai

[Sven Panne, 2013-11-18 14:14:16]

LGTM (rubberstamped)

[Sven Panne, 2014-01-28 07:13:12]

What's the state of this CL? If it's not necessary anymore, let's close it,
otherwise let's land it... :-)

[mathias, 2014-01-29 09:03:38]

https://codereview.chromium.org/68133016/diff/1/src/i18n.js
File src/i18n.js (right):

https://codereview.chromium.org/68133016/diff/1/src/i18n.js#newcode2007
src/i18n.js:2007: if (IS_NULL_OR_UNDEFINED(this)) {
You should use `CHECK_OBJECT_COERCIBLE` here as per step 1 in the spec.
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.no...

[mathias, 2014-01-29 09:05:54]

https://codereview.chromium.org/68133016/diff/1/src/string.js
File src/string.js (right):

https://codereview.chromium.org/68133016/diff/1/src/string.js#newcode212
src/string.js:212: if (IS_NULL_OR_UNDEFINED(this) && !IS_UNDETECTABLE(this)) {
While this is correct, it might be better to just use the
`CHECK_OBJECT_COERCIBLE` macro.

https://codereview.chromium.org/68133016/diff/1/src/string.js#newcode214
src/string.js:214: ["String.prototype.localeCompare"]);
s/localeCompare/normalize/

[Sven Panne, 2014-01-31 08:09:28]

Committed patchset #2 manually as r18972 (presubmit successful).

[arv (Not doing code reviews), 2014-04-10 18:20:09]

FYI

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js
File src/i18n.js (right):

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js#newcode2004
src/i18n.js:2004: throw new $TypeError(ORDINARY_FUNCTION_CALLED_AS_CONSTRUCTOR);
Does the spec really mandate this?

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js#newcode2011
src/i18n.js:2011: var normalizationForm = NORMALIZATION_FORMS.indexOf(form);
Does this need to ensure we are calling the original indexOf?

https://codereview.chromium.org/68133016/diff/130001/src/string.js
File src/string.js (right):

https://codereview.chromium.org/68133016/diff/130001/src/string.js#newcode201
src/string.js:201: var normalizationForm = NORMALIZATION_FORMS.indexOf(form);
same here?

https://codereview.chromium.org/68133016/diff/130001/src/string.js#newcode204
src/string.js:204: + NORMALIZATION_FORMS.join(', ') + '.');
and here

[mathiasb, 2014-04-10 19:16:58]

Shouldn’t this have been behind a flag?

[mnita, 2014-04-10 20:54:20]

On 2014/04/10 19:16:58, mathiasb wrote:
> Shouldn’t this have been behind a flag?

By "behind a flag" you mean for the case when icu is not included?
For that case we return the string untouched. Nothing "explodes."

Or a new flag like "enable_string_normalization"?
But in that case we would end up with hundreds of flags as we add functionality.

[mnita, 2014-04-10 21:19:57]

On 2014/04/10 20:54:20, mnita wrote:
> On 2014/04/10 19:16:58, mathiasb wrote:
> > Shouldn’t this have been behind a flag?
> 
> By "behind a flag" you mean for the case when icu is not included?
> For that case we return the string untouched. Nothing "explodes."
> 
> Or a new flag like "enable_string_normalization"?
> But in that case we would end up with hundreds of flags as we add
functionality.

Now it clicked, you mean a flag under chrome://flags.
I would say we don't need it for this feature.
It is very small, and it was very easily approved for ES6, nobody agreed with
the proposal and the usefulness.
So the chances that is will be removed from the final version are slim to none.

[mnita, 2014-04-10 21:20:29]

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js
File src/i18n.js (right):

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js#newcode2004
src/i18n.js:2004: throw new $TypeError(ORDINARY_FUNCTION_CALLED_AS_CONSTRUCTOR);
On 2014/04/10 18:20:10, arv wrote:
> Does the spec really mandate this?

Hmmmm... Not in spec, sorry.
I will remove this whole 'if'.

https://codereview.chromium.org/68133016/diff/130001/src/i18n.js#newcode2011
src/i18n.js:2011: var normalizationForm = NORMALIZATION_FORMS.indexOf(form);
On 2014/04/10 18:20:10, arv wrote:
> Does this need to ensure we are calling the original indexOf?

Done.

https://codereview.chromium.org/68133016/diff/130001/src/string.js
File src/string.js (right):

https://codereview.chromium.org/68133016/diff/130001/src/string.js#newcode201
src/string.js:201: var normalizationForm = NORMALIZATION_FORMS.indexOf(form);
On 2014/04/10 18:20:10, arv wrote:
> same here?

Done.

https://codereview.chromium.org/68133016/diff/130001/src/string.js#newcode204
src/string.js:204: + NORMALIZATION_FORMS.join(', ') + '.');
On 2014/04/10 18:20:10, arv wrote:
> and here

Done.

[mnita, 2014-04-10 21:56:30]

> It is very small, and it was very easily approved for ES6, nobody agreed with
> the proposal and the usefulness.

Sorry, "nobody agreed" should be "everybody agreed"
:-)

[mathiasb, 2014-04-10 21:57:37]

On 2014/04/10 21:19:57, mnita wrote:
> On 2014/04/10 20:54:20, mnita wrote:
> > On 2014/04/10 19:16:58, mathiasb wrote:
> > > Shouldn’t this have been behind a flag?
> > 
> > By "behind a flag" you mean for the case when icu is not included?
> > For that case we return the string untouched. Nothing "explodes."
> > 
> > Or a new flag like "enable_string_normalization"?
> > But in that case we would end up with hundreds of flags as we add
> functionality.
> 
> Now it clicked, you mean a flag under chrome://flags.

I actually meant the `--harmony` or `--es-staging` flag.

> I would say we don't need it for this feature.
> It is very small, and it was very easily approved for ES6, nobody agreed with
> the proposal and the usefulness.
> So the chances that is will be removed from the final version are slim to
none.

The same thing goes for `String.fromCodePoint` and
`String.prototype.codePointAt` but for some reason the decision there was
different: https://codereview.appspot.com/13816046#msg3

I’m just trying to understand the difference.

[mnita, 2014-04-10 22:23:29]

> The same thing goes for `String.fromCodePoint` and
> `String.prototype.codePointAt` but for some reason the decision there was
> different: https://codereview.appspot.com/13816046#msg3
> 
> I’m just trying to understand the difference.

I don't know the details.

But the spec for code point access APIs went through several rounds of "fixes"
(at least 2 that I know of, one of the update cause by the harmony proposal)
(http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/inde...)

Normalization had no objections, and was a separate feature.
(http://wiki.ecmascript.org/doku.php?id=strawman:unicode_normalization)