WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
168178
[INTL] Change Intl prototypes to plain objects
https://bugs.webkit.org/show_bug.cgi?id=168178
Summary
[INTL] Change Intl prototypes to plain objects
Andy VanWagoner
Reported
2017-02-11 14:32:31 PST
Change Intl prototypes to plain objects
Attachments
Patch
(44.21 KB, patch)
2017-02-11 14:39 PST
,
Andy VanWagoner
no flags
Details
Formatted Diff
Diff
Patch
(49.26 KB, patch)
2017-02-25 13:00 PST
,
Andy VanWagoner
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Andy VanWagoner
Comment 1
2017-02-11 14:39:32 PST
Created
attachment 301274
[details]
Patch
Andy VanWagoner
Comment 2
2017-02-11 14:40:41 PST
https://github.com/tc39/ecma402/issues/122
Build Bot
Comment 3
2017-02-18 04:25:59 PST
Comment on
attachment 301274
[details]
Patch
Attachment 301274
[details]
did not pass jsc-ews (mac): Output:
http://webkit-queues.webkit.org/results/3148910
New failing tests: cdjs-tests.yaml/main.js.ftl-no-cjit cdjs-tests.yaml/main.js.ftl-eager-no-cjit
Yusuke Suzuki
Comment 4
2017-02-18 07:56:43 PST
Comment on
attachment 301274
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=301274&action=review
r=me
> Source/JavaScriptCore/ChangeLog:6 > + Reviewed by NOBODY (OOPS!).
Could you add tests to ensure that the prototypes become plain objects correctly?
Andy VanWagoner
Comment 5
2017-02-18 13:32:08 PST
(In reply to
comment #4
)
> Comment on
attachment 301274
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=301274&action=review
> > r=me > > > Source/JavaScriptCore/ChangeLog:6 > > + Reviewed by NOBODY (OOPS!). > > Could you add tests to ensure that the prototypes become plain objects > correctly?
Do you have any suggestions on how to do this? The following are true before this change. shouldBe("Object.getPrototypeOf(Intl.Collator.prototype)", "Object.prototype"); shouldBe("Object.prototype.toString.call(Intl.Collator.prototype)", "'[object Object]'"); There are already tests in this patch that throw when trying to use the prototype object with compare, format, and resolvedOptions.
Andy VanWagoner
Comment 6
2017-02-18 13:37:28 PST
(In reply to
comment #3
)
> Comment on
attachment 301274
[details]
> Patch > >
Attachment 301274
[details]
did not pass jsc-ews (mac): > Output:
http://webkit-queues.webkit.org/results/3148910
> > New failing tests: > cdjs-tests.yaml/main.js.ftl-no-cjit > cdjs-tests.yaml/main.js.ftl-eager-no-cjit
How do I go about finding the specific cause of the performance regression? My gut feeling is the removal of the invalidated optimization in String#localeCompare.
Andy VanWagoner
Comment 7
2017-02-25 13:00:05 PST
Created
attachment 302762
[details]
Patch
Andy VanWagoner
Comment 8
2017-02-25 15:01:56 PST
Comment on
attachment 302762
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=302762&action=review
> Source/JavaScriptCore/builtins/StringPrototype.js:240 > +
Normally I'd just have a simple variable, but I'm not confident I can construct a Collator yet, and I've only ever seen functions at the top level of a builtins file. var defaultCollator = new @Collator();
> LayoutTests/js/script-tests/intl-collator.js:213 > +shouldBe("Object.prototype.toString.call(Intl.Collator.prototype)", "'[object Object]'");
Here's the check to observe the new behavior. Only the constructor property would have failed before this patch, though.
> LayoutTests/js/script-tests/intl-collator.js:235 > +shouldThrow("Intl.Collator.prototype.compare", "'TypeError: Intl.Collator.prototype.compare called on value that\\'s not an object initialized as a Collator'");
Here is the real change in behavior. Trying to get the bound compare function, or resolvedOptions on the prototype directly will throw now.
> LayoutTests/js/script-tests/intl-numberformat.js:283 > +shouldBe("Intl.NumberFormat('fr').format(1234.567)", "'1\\xA0234,567'");
I changed this to an escaped code because I couldn't manage to get my text editor to insert the right space character.
JF Bastien
Comment 9
2017-04-13 10:31:10 PDT
Comment on
attachment 302762
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=302762&action=review
r=me
>> LayoutTests/js/script-tests/intl-numberformat.js:283 >> +shouldBe("Intl.NumberFormat('fr').format(1234.567)", "'1\\xA0234,567'"); > > I changed this to an escaped code because I couldn't manage to get my text editor to insert the right space character.
One might say your editor broke the non-breaking spaces.
Andy VanWagoner
Comment 10
2017-04-13 16:24:53 PDT
(In reply to JF Bastien from
comment #9
)
> Comment on
attachment 302762
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=302762&action=review
> > r=me > > >> LayoutTests/js/script-tests/intl-numberformat.js:283 > >> +shouldBe("Intl.NumberFormat('fr').format(1234.567)", "'1\\xA0234,567'"); > > > > I changed this to an escaped code because I couldn't manage to get my text editor to insert the right space character. > > One might say your editor broke the non-breaking spaces.
:) I'm not a committer, so if this is good to go, can you add the commit-queue+ flag?
JF Bastien
Comment 11
2017-04-13 16:27:58 PDT
Comment on
attachment 302762
[details]
Patch cq+
WebKit Commit Bot
Comment 12
2017-04-13 16:51:44 PDT
Comment on
attachment 302762
[details]
Patch Clearing flags on attachment: 302762 Committed
r215349
: <
http://trac.webkit.org/changeset/215349
>
WebKit Commit Bot
Comment 13
2017-04-13 16:51:46 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug