Intl flavor throws exception when using Intl.NumberFormatter#format

[Evan Ricketts]

Issue Description

I integrated JSC to my react-native project following the directions found in the README.
I used the intl flavour, as my app needs to support multiple languages and locales.
The app runs fine, so it appears the integration of the newer JSC went off without a hitch.

However, the following block of code will throw the exception Error: Failed to format a number.:

const fmtLocale = `en-US`;
const fmtOpts = { minimumFractionDigits: 2, maximumFractionDigits: 2 };
const numberFormat = new Intl.NumberFormat(fmtLocale, fmtOpts);
const formatted = numberFormat.format(1.25);

That block of code runs without a hitch on the JSC which comes with react-native by default.

And note that the line that is throwing is the call to numberFormat.format(1.25); the Intl object has all the expected members, and said members instantiate without an exceptions being generated (so I don't believe its an issue of mistakenly using the non-intl flavor of JSC...)

Version, config, any additional info

• react-native v0.54.4
• jsc-android v224109.0.0 (with android-jsc being forced to android-jsc-intl r224109)
• Android 7.1.1 (emulator)

If any other pertinent information comes to mind, I'll be sure to update; otherwise if any more info is needed, or you'd like me to put together a repo with a minimum reproduction, I'm happy to provide greater detail.

This issue may be related to #36 and #47.

Edit: added some clarifications.

[Evan Ricketts]

The plot thickens -- if I force resolve the non intl flavor of android-jsc in my build.gradle config, not only does the above code block execute fine, but it appears that the (more complex) language i18n functionality also works properly, at least with ru-RU as the locale.

I've confirmed that the build.gradle was being respected by inspecting the JSC related .so files in the generated apk, and comparing the sizes against the known configuration build sizes; so I know that the intl and non-intl flavors haven't somehow become reversed... very puzzling behavior!

[Maciej Kmak]

@ericketts is there any chance you can send me *.apk file where it actually works?

edit
Turning off intl just sets everything to en-US locale, instead of crashing with intl turned on...

[Evan Ricketts]

@Kmakinator you'd like me to send you an apk built with the non-intl flavour? That's the only case where it works presently...

I'm happy to do that, but would need to put together a minimal repro (since the actual APK contains IP I cannot release), so want to make sure I understand you properly before spending the time creating the minimal repro...

[Evan Ricketts]

So a bit more information, it turns out that unbeknownst to me, in the case of the non-intl flavored JSC being used, the Intl API was being polyfilled. If I prevent the polyfill from happening, everything is broken as you'd expect.

So this ticket now is solely about the intl flavor JSC failing when calling Intl.NumberFormat#format as outlined in the root comment.

[DanielZlotin]

Thanks for reporting, basically a duplicate of #36. closing to keep all discussions in 1 topic