RESOLVED FIXED Bug 216193
[JSC] Align legacy Intl constructor behavior to spec
https://bugs.webkit.org/show_bug.cgi?id=216193
Summary [JSC] Align legacy Intl constructor behavior to spec
Yusuke Suzuki
Reported 2020-09-04 14:37:48 PDT
...
Attachments
Patch (43.84 KB, patch)
2020-09-04 16:17 PDT, Yusuke Suzuki
no flags
Patch (44.60 KB, patch)
2020-09-04 16:33 PDT, Yusuke Suzuki
no flags
Patch (46.85 KB, patch)
2020-09-04 17:58 PDT, Yusuke Suzuki
no flags
Patch (46.85 KB, patch)
2020-09-04 18:00 PDT, Yusuke Suzuki
no flags
Yusuke Suzuki
Comment 1 2020-09-04 16:17:09 PDT
Yusuke Suzuki
Comment 2 2020-09-04 16:21:03 PDT
Comment on attachment 408039 [details] Patch Will update
Yusuke Suzuki
Comment 3 2020-09-04 16:33:20 PDT
Darin Adler
Comment 4 2020-09-04 16:36:34 PDT
Comment on attachment 408042 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=408042&action=review This all looks good, but I’d like to wait until EWS tests are passing and I’ll review then if no one has done it yet. > Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp:114 > + IntlDateTimeFormat* dtf = IntlDateTimeFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); How about "format" instead of "dtf"? And auto perhaps? auto format = ... > Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:117 > + IntlNumberFormat* nf = IntlNumberFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); auto format =
Yusuke Suzuki
Comment 5 2020-09-04 17:57:02 PDT
Comment on attachment 408042 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=408042&action=review >> Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp:114 >> + IntlDateTimeFormat* dtf = IntlDateTimeFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); > > How about "format" instead of "dtf"? And auto perhaps? > > auto format = ... Changed to auto*. >> Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:117 >> + IntlNumberFormat* nf = IntlNumberFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); > > auto format = Changed to `auto*`. It is good that we know this is a pointer for readability.
Yusuke Suzuki
Comment 6 2020-09-04 17:58:42 PDT
Yusuke Suzuki
Comment 7 2020-09-04 17:58:50 PDT
Updated.
Yusuke Suzuki
Comment 8 2020-09-04 18:00:05 PDT
Darin Adler
Comment 9 2020-09-04 21:27:38 PDT
Comment on attachment 408058 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=408058&action=review > Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp:114 > + auto* dtf = IntlDateTimeFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); auto format > Source/JavaScriptCore/runtime/IntlDateTimeFormatPrototype.cpp:146 > + auto* dateTimeFormat = jsDynamicCast<IntlDateTimeFormat*>(vm, callFrame->thisValue()); I’d like auto format here too > Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:117 > + auto* nf = IntlNumberFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); auto format
Darin Adler
Comment 10 2020-09-04 21:28:44 PDT
Comment on attachment 408042 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=408042&action=review >>> Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:117 >>> + IntlNumberFormat* nf = IntlNumberFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); >> >> auto format = > > Changed to `auto*`. It is good that we know this is a pointer for readability. Part of my suggestion was "format" instead of "nf". Also, I strongly suggest "auto" instead of "auto*" so we can change return values to smart pointers without touching all the code. There are plenty of things that act like pointers that don’t work with auto*.
EWS
Comment 11 2020-09-04 21:53:21 PDT
Committed r266655: <https://trac.webkit.org/changeset/266655> All reviewed patches have been landed. Closing bug and clearing flags on attachment 408058 [details].
Radar WebKit Bug Importer
Comment 12 2020-09-04 21:54:15 PDT
Yusuke Suzuki
Comment 13 2020-09-05 13:29:45 PDT
Comment on attachment 408042 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=408042&action=review >>>> Source/JavaScriptCore/runtime/IntlNumberFormatPrototype.cpp:117 >>>> + IntlNumberFormat* nf = IntlNumberFormat::unwrapForOldFunctions(globalObject, callFrame->thisValue()); >>> >>> auto format = >> >> Changed to `auto*`. It is good that we know this is a pointer for readability. > > Part of my suggestion was "format" instead of "nf". > > Also, I strongly suggest "auto" instead of "auto*" so we can change return values to smart pointers without touching all the code. There are plenty of things that act like pointers that don’t work with auto*. I think auto* in JavaScriptCore (not in WebCore) has more meaning than `auto*` in WebCore. The reason is that, in JSC, we are having GC-managed JSCell derived objects. And we are using it via raw pointer. So, `auto*` in JSC tells us that this is likely this value is GC-managed JSCell. For non-JSCell things, possibly using `auto` is better. But for JSCell cases, I think `auto*` is nice for readability. When reading the code, `auto` cannot offer information about the ownership management (if it is JSCell, it is GC-managed, and this is largely different from the other C++ objects). But `auto*` can tell us that this is a raw pointer, so we should care about ownership carefully, if it is JSCell, we should consider it as GC-managed. And if it is not JSCell, then we should be careful about the ownership of this raw pointer.
Yusuke Suzuki
Comment 14 2020-09-05 21:56:06 PDT
Note You need to log in before you can comment on or make changes to this bug.