Bug 178062 - [JSC] Use fastJoin in Array#toString
Summary: [JSC] Use fastJoin in Array#toString
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-10-07 23:41 PDT by Yusuke Suzuki
Modified: 2017-11-15 13:10 PST (History)
14 users (show)

See Also:


Attachments
Patch (20.86 KB, patch)
2017-10-07 23:52 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (20.70 KB, patch)
2017-10-07 23:53 PDT, Yusuke Suzuki
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2017-10-07 23:41:08 PDT
[JSC] Use fastJoin in Array#toString
Comment 1 Yusuke Suzuki 2017-10-07 23:52:20 PDT
Created attachment 323124 [details]
Patch
Comment 2 Yusuke Suzuki 2017-10-07 23:53:45 PDT
Created attachment 323125 [details]
Patch
Comment 3 Darin Adler 2017-10-08 00:10:11 PDT
Comment on attachment 323125 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323125&action=review

> Source/JavaScriptCore/runtime/ArrayPrototype.cpp:672
> +        if (element.isUndefinedOrNull())
> +            continue;

Why does the ENABLE(INTL) version put in extra commas, but the !ENABLE(INTL) version doesn’t? There is no stringJoiner.appendEmptyString() here. Does your patch change behavior in one of the two cases? Do we have test coverage?

Can we put ENABLE(INTL) around less of the function? It seems like the code is *almost* identical. There are only three differences.

> Source/JavaScriptCore/runtime/JSStringJoiner.h:41
> +    void appendInt32(VM&, int32_t);
> +    void appendDouble(VM&, double);

I probably would have used overloading and named these both appendNumber or appendNumeral. I believe that if someone used it with any other type besides int32_t and double, it would not compile because the overloading would be ambiguous. That’s how the underlying numericStrings.add works.

But your way is clear and explicit so I am OK with it.
Comment 4 Darin Adler 2017-10-08 00:21:21 PDT
Comment on attachment 323125 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323125&action=review

>> Source/JavaScriptCore/runtime/ArrayPrototype.cpp:672
>> +            continue;
> 
> Why does the ENABLE(INTL) version put in extra commas, but the !ENABLE(INTL) version doesn’t? There is no stringJoiner.appendEmptyString() here. Does your patch change behavior in one of the two cases? Do we have test coverage?
> 
> Can we put ENABLE(INTL) around less of the function? It seems like the code is *almost* identical. There are only three differences.

On reflection, obviously the patch doesn’t change anything because this is toLocaleString, not toString, but still this is strange.
Comment 5 Yusuke Suzuki 2017-10-23 04:39:44 PDT
Comment on attachment 323125 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323125&action=review

Thank you!

>>> Source/JavaScriptCore/runtime/ArrayPrototype.cpp:672
>>> +            continue;
>> 
>> Why does the ENABLE(INTL) version put in extra commas, but the !ENABLE(INTL) version doesn’t? There is no stringJoiner.appendEmptyString() here. Does your patch change behavior in one of the two cases? Do we have test coverage?
>> 
>> Can we put ENABLE(INTL) around less of the function? It seems like the code is *almost* identical. There are only three differences.
> 
> On reflection, obviously the patch doesn’t change anything because this is toLocaleString, not toString, but still this is strange.

Yeah, this patch does not change toLocaleString. But right, it looks incorrect.
According to the spec[1], we should take ENABLE(INTL) version's behavior.
I'll clean up this part and add a test.
[1]: https://tc39.github.io/ecma402/#sup-array.prototype.tolocalestring

>> Source/JavaScriptCore/runtime/JSStringJoiner.h:41
>> +    void appendDouble(VM&, double);
> 
> I probably would have used overloading and named these both appendNumber or appendNumeral. I believe that if someone used it with any other type besides int32_t and double, it would not compile because the overloading would be ambiguous. That’s how the underlying numericStrings.add works.
> 
> But your way is clear and explicit so I am OK with it.

OK, I'll use overloading version since the underlying numericStrings.add follows this. I'll change them to `appendNumber`.
Comment 6 Yusuke Suzuki 2017-10-23 04:50:32 PDT
Committed r223834: <https://trac.webkit.org/changeset/223834>
Comment 7 Radar WebKit Bug Importer 2017-11-15 13:10:17 PST
<rdar://problem/35568901>