profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/JacksonGL/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Liang Gong JacksonGL @facebook @ucberkeley CA https://jacksongl.github.io Research Scientist @ Facebook

JacksonGL/NPM-Vuln-PoC 31

Vulnerabilities discovered in npm repository [Berkeley PL & Security Research].

JacksonGL/jitprof-visualization 7

Warning Visualization for JIT-unfriendly Code in JavaScript

Glimpse/Glimpse.Client.Hud 4

Glimpse Client - Heads-up-display (embedded client)

JacksonGL/mem-vis-pack 4

A memory snapshot and visualization tool for node-chakracore.

JacksonGL/jacksongl.github.io 3

Liang Gong's Homepage

DrakeW/projectscope 1

MVP dashboard for ProjectScope, using new gems architecture developed by AV folks

JacksonGL/MacLockScreen 1

Macbook lock screen without disconnect from Wi-Fi

PR closed facebook/hermes

Add LTO to Release and MinSizeRel builds in CMake CLA Signed fb-exported

Summary: When building with the CMake build mode "Release" or "MinSizeRel", turn on LTO in compiler flags and linker flags. This will impact builds of binaries like hermes and hermesc, as well as the libraries packaged in our OSS builds.

There are a couple advantages to turning on LTO, one of which is a size difference: The hermes binary changes from 3.4 MB to 2.5 MB for -Os (MinSizeRel) and from 3.9 MB to 3.3 MB with -O3 (Release) The second advantage is performance, although in this case Octane scores didn't seem to be statistically significantly affected.

These benefits can extend to the builds for apps like libhermes.so, but the benefits aren't as noticeable. If someone statically linked their app libraries they might get more benefit out of it.

Differential Revision: D22529505

+9 -0

2 comments

1 changed file

dulinriley

pr closed time in 14 minutes

pull request commentfacebook/hermes

Adding Documentation for ECMA-402

@mganandraj has updated the pull request. You must reimport the pull request before landing.

mganandraj

comment created time in an hour

pull request commentfacebook/hermes

Adding Documentation for ECMA-402

@Huxpro has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

mganandraj

comment created time in an hour

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Limitations across Android SDKs
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases. e.g. `-Infinity` may get formatted as '-∞E0' instead of expected '-∞'. Another manifestation of the issues is that the formatToParts may return 4 parts instead of 2.
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal'. For e.g. the second part of "100ac" gets reported as "literal" instead of "compact"

I really appreciate this example. Love it!

mganandraj

comment created time in an hour

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Limitations across Android SDKs
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases. e.g. `-Infinity` may get formatted as '-∞E0' instead of expected '-∞'. Another manifestation of the issues is that the formatToParts may return 4 parts instead of 2.
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal'. For e.g. the second part of "100ac" gets reported as "literal" instead of "compact"
+
+### Android 9 and older (SDK < 29)
+
+- There are some failures likely due to older Unicode and CLDR version, which are hard to generalize. Some examples are,
+  - `Intl.NumberFormat`: 'Percent' is not accepted as a unit.
+  - `Intl.NumberFormat`: unit symbols difference, kph vs km/h
+  - Some issue in significant digit precision, which is not yet looked into the details.
+
+### Android 8.0 – 8.1 and older (SDK < 28)
+
+- `Intl.getCanonicalLocales`: Some differences in the keyword values due to CLDR/Unicode version difference (Expected SameValue(«und-u-tz-utc», «und-u-tz-gmt») to be true)
+- `Intl.NumberFormat`: CompactFormatter doesn't respect the precision inputs (Expected SameValue(«9,900만», «9877만») to be true; Expected SameValue(«990M», «988M») to be true).
+
+### Android 7.0 - 7.1 and older (SDK < 26)
+
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences Expected SameValue(«und-u-ms-imperial», «und-u-ms-uksystem») to be true
+
+### Android 7.0 - 7.1 and older (SDK < 24)
+
+- `Intl.Collator`: Doesn't canonically decompose the input strings. Canonically equivalent string with non-identical code points may not match.
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences (Expected SameValue(«und-u-ca-ethiopic-amete-alem», «und-u-ca-ethioaa») to be true; Expected SameValue(«und-u-ks-primary», «und-u-ks-level1») to be true)

There are still some Expected SameValue here that might confuse our reader

mganandraj

comment created time in an hour

issue commentfacebook/hermes

Turn off annoying warnings on build

hermesFlagsRelease: ["-w"] works for Android, but if you have Hermes enabled in iOS, it still prints lots of warnings during the build.

iagormoraes

comment created time in an hour

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+# Overview
+
+This document describes the current state of Android implementation of Intl APIs(formally ECMA-402 specification) in Hermes JavaScript engine. ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and typically adds new capabilities typically as,
+- New Intl service constructors (for e.g. Intl.Collator, Intl.NumberFormat etc...) or extending existing ones by accepting more parameters
+- New functions or properties in the Intl object prototypes (for e.g. Intl.Collator.prototype.compare)
+- New locale aware functions in standard Javascript object prototypes (for e.g. String.prototype.localeCompare)
+
+One standard internationalization implementation strategy followed by other engines, is to bundle a library and data (typically [icu](http://site.icu-project.org/)) along with the application package. This guarantees deterministic functionality at the cost of applications package bloat.  We decided to consume the Android platform libraries and data for space efficiency, but at the cost of some variance in behaviour across  Android platforms.
+
+# ECMA-402 Compliance

Ah .. I thought about your question last week .. but missed actually replying to it !

I am hoping we will continue to keep the docx as a richer detailed documentation for the Intl developers and the markdown as the quick reference for Intl consumers .. I see that many aspects of our representations in the docx can be useful for the consumers too, but will also also make the contents complicated .. I think we could work on it as part of our next wave of Intl feature developement ..

mganandraj

comment created time in 2 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases such as Infinity (e.g. Expected SameValue(«-∞E0», «-∞») to be true).
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal' (Compact short: 987654321: parts[1].type Expected SameValue(«literal», «compact») to be true)

Oh, so it's error from test262 (well, test402 I guess). I see.

Since you already explained them in prose. Maybe we can just link to those tests if people are interested in looking at the exact edge cases.

mganandraj

comment created time in 2 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases such as Infinity (e.g. Expected SameValue(«-∞E0», «-∞») to be true).
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal' (Compact short: 987654321: parts[1].type Expected SameValue(«literal», «compact») to be true)
+- `Intl.NumberFormat`: `formatToParts` function doesn't produce expected result with Scientific/Engineering notation and input Infinity (`-Infinity` - engineering: length Expected SameValue(«4», «2») to be true).
+
+### Android 9 and older (SDK < 29)
+
+- There are some failures likely due to older Unicode and CLDR version, which are hard to generalize. Some examples are,
+  - `Intl.NumberFormat`: 'Percent' is not accepted as a unit.
+  - `Intl.NumberFormat`: unit symbols difference, kph vs km/h
+  - Some issue in significant digit precision, which is not yet looked into the details.
+
+### Android 8.0 – 8.1 and older (SDK < 28)
+
+- `Intl.getCanonicalLocales`: Some differences in the keyword values due to CLDR/Unicode version difference (Expected SameValue(«und-u-tz-utc», «und-u-tz-gmt») to be true)
+- `Intl.NumberFormat`: CompactFormatter doesn't respect the precision inputs (Expected SameValue(«9,900만», «9877만») to be true; Expected SameValue(«990M», «988M») to be true).
+
+### Android 7.0 - 7.1 and older (SDK < 26)
+
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences Expected SameValue(«und-u-ms-imperial», «und-u-ms-uksystem») to be true
+
+### Android 7.0 - 7.1 and older (SDK < 24)
+
+- `Intl.Collator`: Doesn't canonically decompose the input strings. Canonically equivalent string with non-identical code points may not match.
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences (Expected SameValue(«und-u-ca-ethiopic-amete-alem», «und-u-ca-ethioaa») to be true; Expected SameValue(«und-u-ks-primary», «und-u-ks-level1») to be true)
+- `Intl.NumberFormat`: Unit style does not work.
+- `Intl.NumberFormat`: There are issues in the precision configuration due to lack of APIs.
+- `Intl.DateFormat`: There are issues with the calendar configuration which needs to be dug into.
+
+### SDK < 21 and older
+
+On platforms before 21, `Locale.forLanguageTag()` is not available, hence we can't construct `java.util.Locale` object from locale tag. Hence, we fallback to English for any locale input.
+
+# Internationalization framework in Android Platform
+
+Our implementation is essentially projecting the Android platform provided internationalization facilities through the ECMA-402 specified services. It implies that the results of running the same code may vary between devices running different versions of Android.
+
+Android platform internationalization libraries have been based on [ICU4j project](https://unicode-org.github.io/icu-docs/#/icu4j). Version of ICU4j and the backing [CLDR data](http://cldr.unicode.org/) varies across Android platform versions. Also, the ICU APIs were never exposed directly, but only through wrappers and aliases. This results in significant variance in internationalization API surface and data across platform versions.
+
+The following table summarizes ICU, CLDR and Unicode versions available on the Android platforms.
+
+### Platform 24+ where ICU4j APIs are available.
+
+| Android Platform Version | ICU | Unicode | CLDR
+| --- | --- | --- | --- |
+| Android 11 (API level 30) | ICU4J 66.1 ([ref](https://android.googlesource.com/platform/external/icu/+/refs/heads/android11-mainline-release/icu4j/readme.html)) | Unicode 13 beta | CLDR 36.1 |
+| Android 10 (API level 29) | ICU4j 63.2 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 34 | Unicode 11.0 |
+| Android 9 (API level 28) | ICU4j 60.2 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 32.0.1 | Unicode 10.0 |
+| Android 8.0 - 8.1 (API levels 26 - 27) | ICU4j 58.2( [ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 30.0.3 | Unicode 9.0 |
+| Android 7.0 - 7.1 (API levels 24 - 25) | ICU4j 56 ([ref](https://developer.android.com/guide/topics/resources/internationalization))| CLDR 28 | Unicode 8.0 |
+
+
+### Pre-24 platforms
+
+| Android Platform Version | ICU | Unicode | CLDR
+| --- | --- | --- | --- |
+| Android 6.0 (API level 23) | ICU4j 55.1 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 27.0.1 | Unicode 7.0 |
+| Android 5.0 (API levels 21–22) | ICU4j 53 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 25 | Unicode 6.3 |
+| Android 4.4 (API levels 19–20) | ICU4j 51 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 23 | Unicode 6.2 |
+| Android 4.3 (API level 18) | ICU4j 50 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 22.1 | Unicode 6.2 |
+| Android 4.1 (API levels 16–17) | ICU4j 4.8 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 2.0 | Unicode 6.0 |  
+  
+<br />
+
+In summary,

It's a "maybe" suggestion so I'm fine whatever you choose ;)

mganandraj

comment created time in 2 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues

Makese sense ..

mganandraj

comment created time in 2 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases such as Infinity (e.g. Expected SameValue(«-∞E0», «-∞») to be true).
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal' (Compact short: 987654321: parts[1].type Expected SameValue(«literal», «compact») to be true)
+- `Intl.NumberFormat`: `formatToParts` function doesn't produce expected result with Scientific/Engineering notation and input Infinity (`-Infinity` - engineering: length Expected SameValue(«4», «2») to be true).
+
+### Android 9 and older (SDK < 29)
+
+- There are some failures likely due to older Unicode and CLDR version, which are hard to generalize. Some examples are,
+  - `Intl.NumberFormat`: 'Percent' is not accepted as a unit.
+  - `Intl.NumberFormat`: unit symbols difference, kph vs km/h
+  - Some issue in significant digit precision, which is not yet looked into the details.
+
+### Android 8.0 – 8.1 and older (SDK < 28)
+
+- `Intl.getCanonicalLocales`: Some differences in the keyword values due to CLDR/Unicode version difference (Expected SameValue(«und-u-tz-utc», «und-u-tz-gmt») to be true)
+- `Intl.NumberFormat`: CompactFormatter doesn't respect the precision inputs (Expected SameValue(«9,900만», «9877만») to be true; Expected SameValue(«990M», «988M») to be true).
+
+### Android 7.0 - 7.1 and older (SDK < 26)
+
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences Expected SameValue(«und-u-ms-imperial», «und-u-ms-uksystem») to be true
+
+### Android 7.0 - 7.1 and older (SDK < 24)
+
+- `Intl.Collator`: Doesn't canonically decompose the input strings. Canonically equivalent string with non-identical code points may not match.
+- `Intl.getCanonicalLocales`: Unicode/CLDR version differences (Expected SameValue(«und-u-ca-ethiopic-amete-alem», «und-u-ca-ethioaa») to be true; Expected SameValue(«und-u-ks-primary», «und-u-ks-level1») to be true)
+- `Intl.NumberFormat`: Unit style does not work.
+- `Intl.NumberFormat`: There are issues in the precision configuration due to lack of APIs.
+- `Intl.DateFormat`: There are issues with the calendar configuration which needs to be dug into.
+
+### SDK < 21 and older
+
+On platforms before 21, `Locale.forLanguageTag()` is not available, hence we can't construct `java.util.Locale` object from locale tag. Hence, we fallback to English for any locale input.
+
+# Internationalization framework in Android Platform
+
+Our implementation is essentially projecting the Android platform provided internationalization facilities through the ECMA-402 specified services. It implies that the results of running the same code may vary between devices running different versions of Android.
+
+Android platform internationalization libraries have been based on [ICU4j project](https://unicode-org.github.io/icu-docs/#/icu4j). Version of ICU4j and the backing [CLDR data](http://cldr.unicode.org/) varies across Android platform versions. Also, the ICU APIs were never exposed directly, but only through wrappers and aliases. This results in significant variance in internationalization API surface and data across platform versions.
+
+The following table summarizes ICU, CLDR and Unicode versions available on the Android platforms.
+
+### Platform 24+ where ICU4j APIs are available.
+
+| Android Platform Version | ICU | Unicode | CLDR
+| --- | --- | --- | --- |
+| Android 11 (API level 30) | ICU4J 66.1 ([ref](https://android.googlesource.com/platform/external/icu/+/refs/heads/android11-mainline-release/icu4j/readme.html)) | Unicode 13 beta | CLDR 36.1 |
+| Android 10 (API level 29) | ICU4j 63.2 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 34 | Unicode 11.0 |
+| Android 9 (API level 28) | ICU4j 60.2 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 32.0.1 | Unicode 10.0 |
+| Android 8.0 - 8.1 (API levels 26 - 27) | ICU4j 58.2( [ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 30.0.3 | Unicode 9.0 |
+| Android 7.0 - 7.1 (API levels 24 - 25) | ICU4j 56 ([ref](https://developer.android.com/guide/topics/resources/internationalization))| CLDR 28 | Unicode 8.0 |
+
+
+### Pre-24 platforms
+
+| Android Platform Version | ICU | Unicode | CLDR
+| --- | --- | --- | --- |
+| Android 6.0 (API level 23) | ICU4j 55.1 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 27.0.1 | Unicode 7.0 |
+| Android 5.0 (API levels 21–22) | ICU4j 53 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 25 | Unicode 6.3 |
+| Android 4.4 (API levels 19–20) | ICU4j 51 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 23 | Unicode 6.2 |
+| Android 4.3 (API level 18) | ICU4j 50 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 22.1 | Unicode 6.2 |
+| Android 4.1 (API levels 16–17) | ICU4j 4.8 ([ref](https://developer.android.com/guide/topics/resources/internationalization)) | CLDR 2.0 | Unicode 6.0 |  
+  
+<br />
+
+In summary,

Xuan.. It makes sense to move it there .. But as it is a summary of the library support on each platform, it make sense to keep it here as well .. It is a tough one .. Shall i keep it here as it for now being ?

mganandraj

comment created time in 2 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases such as Infinity (e.g. Expected SameValue(«-∞E0», «-∞») to be true).
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal' (Compact short: 987654321: parts[1].type Expected SameValue(«literal», «compact») to be true)

I've copied out the assert failure statement as it .. my bad :) I'm making the text better readable.

Also, please note that I tried to document the test code with these failures. For instance take a look at : https://github.com/facebook/hermes/blob/master/android/intltest/java/com/facebook/hermes/test/HermesIntlNumberFormatTest.java

mganandraj

comment created time in 4 hours

Pull request review commentfacebook/hermes

Adding Documentation for ECMA-402

+---
+id: intl
+title: Internationalization APIs
+---
+
+This document describes the current state of Android implementation of the [ECMAScript Internationalization API Specification](https://tc39.es/ecma402/) (ECMA-402, or `Intl`). ECMA-402 is still evolving and the latest iteration is [7th edition](https://402.ecma-international.org/7.0/) which was published in June 2020. Each new edition is built on top of the last one and adds new capabilities typically as,
+- New `Intl` service constructors (e.g. `Intl.Collator`, `Intl.NumberFormat` etc.) or extending existing ones by accepting more parameters
+- New functions or properties in `Intl` objects (e.g. `Intl.Collator.prototype.compare`)
+- New locale aware functions in standard Javascript object prototypes (e.g. `String.prototype.localeCompare`)
+
+One popular implementation strategy followed by other engines, is to bundle an internationalization framework (typically [ICU](http://site.icu-project.org/)) along with the application package. This guarantees deterministic behaviours at the cost of applications package bloat. We decided to consume the Android platform provided facilities for space efficiency, but at the cost of some variance in behaviours across Android platforms.
+
+# ECMA-402 Compliance
+
+## Supported
+
+- `Intl.Collator`
+  - `Intl.Collator.supportedLocalesOf`
+  - `Intl.Collator.prototype.compare`
+  - `Intl.Collator.prototype.resolvedOptions`
+
+- `Intl.NumberFormat`
+  - `Intl.NumberFormat.supportedLocalesOf`
+  - `Intl.NumberFormat.prototype.format`
+  - `Intl.NumberFormat.prototype.formatToParts`
+  - `Intl.NumberFormat.prototype.resolvedOptions`
+
+- `Intl.DateTimeFormat`
+  - `Intl.DateTimeFormat.supportedLocalesOf`
+  - `Intl.DateTimeFormat.prototype.format`
+  - `Intl.DateTimeFormat.prototype.formatToParts`
+  - `Intl.DateTimeFormat.prototype.resolvedOptions`
+
+- `Intl.getCanonicalLocales`
+
+- `String.prototype`
+  - `localeCompare`
+  - `toLocaleLowerCase`
+  - `toLocaleUpperCase`
+
+- `Array.prototype`
+  - `toLocaleString`
+
+- `Number.prototype`
+  - `toLocaleString`
+
+- `Date.prototype`
+  - `toLocaleString`
+  - `toLocaleDateString`
+  - `toLocaleTimeString`
+
+## Not yet supported
+
+- [`Intl.PluralRules`](https://tc39.es/ecma402/#pluralrules-objects)
+
+- [`Intl.RelativeTimeFormat`](https://tc39.es/ecma402/#relativetimeformat-objects)
+
+- [`Intl.DisplayNames`](https://tc39.es/proposal-intl-displaynames/#sec-intl-displaynames-constructor)
+
+- [`Intl.ListFormat`](https://tc39.es/proposal-intl-list-format/#sec-intl-listformat-constructor)
+
+- [`Intl.Locale`](https://tc39.es/ecma402/#sec-intl-locale-constructor)
+
+- `Intl.DateTimeFormat` properties
+   - [`dateStyle/timeStyle`](https://tc39.es/proposal-intl-datetime-style/)
+   - [`dayPeriod`](https://github.com/tc39/ecma402/issues/29)
+   - [`fractionalSecondDigits`](https://github.com/tc39/ecma402/pull/347)
+- [`BigInt.prototype.toLocaleString`](https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
+
+## Excluded
+
+- `Intl.DateTimeFormat`: [`formatMatcher`](https://tc39.es/ecma402/#sec-basicformatmatcher) parameter is not respected. The parameter enables the implementation to pick the best display format when it supports only a subset of all possible formats. ICU library in Android platform and hence our implementation allows all subsets and formats which makes this `formatMatcher` property unnecessary.
+
+## Known Issues
+
+### Android 11
+
+- The keys of the object returned by `resolvedOptions` function in all `Intl` services are not deterministically ordered as prescribed by spec.
+- DateFormat: ECMAScript [beginning of time](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-time-values-and-time-range) (-8,640,000,000,000,000), is formatted as `November 271817`, instead of expected `April 271822`.
+- `Intl.NumberFormat` implementation has some rough edges in supporting the following properties,
+  - `style`: 'unit'
+  - `notation`: 'compact'
+  - `signDisplay`
+  - `currencyFormat`
+
+### Android 10 and older (SDK < 30)
+
+- `Intl.NumberFormat`: Scientific notation formatting has issues on some cases such as Infinity (e.g. Expected SameValue(«-∞E0», «-∞») to be true).
+- `Intl.NumberFormat`: Compact notation `formatToParts` doesn't identify unit, hence we report unit as 'literal' (Compact short: 987654321: parts[1].type Expected SameValue(«literal», «compact») to be true)
+- `Intl.NumberFormat`: `formatToParts` function doesn't produce expected result with Scientific/Engineering notation and input Infinity (`-Infinity` - engineering: length Expected SameValue(«4», «2») to be true).

This one is strange .. When i was testing a few months back, -Inifinity was foamtted as something like ∞E0 on older than platform 30 .. but from a quick test, it doesn't seem to be the case anymore .. May be the icu libraries are getting updated over the air .. I'll keep the entry anyways but make the text clearer.

mganandraj

comment created time in 4 hours

issue commentfacebook/hermes

Can we load multiple hermes' bundles in a single VM?

@nthtrung09it my suggestion is to ask for help in React Native, since it isn't caused by Hermes per se.

RajeshBatth

comment created time in 6 hours

push eventfacebook/hermes

Riley Dulin

commit sha 64071c6187cb20a9e29b05670899714eded28b02

Support lookup from snapshot ID to object Summary: In order to support querying objects in a heap snapshot for things like object properties, we need to support mapping from an ID back to an object. The particular interaction that causes this is hovering over an object in the snapshot for a second while the debugger is attached. Maintaining a fast lookup table would be very wasteful of memory for the < 100 objects that someone would query. So instead, do a lazy search of all objects whenever one is requested. In practice when I tried this on a small heap (< 1 MB) it didn't take long at all. I'd rather have the UI stall then use up 2x the memory for tracking objects. After the first time this occurs, the ID -> object mapping is cached and kept up to date until the object dies. That means going back and forth between a few objects will be fast. If people in the wild complain about the performance of the UI, we might need to revisit this decision, but I doubt it'll be a problem in practice. Reviewed By: neildhar Differential Revision: D27834673 fbshipit-source-id: 844b1ec13c80176b9fdb0c44616273ecf23ec08a

view details

push time in 6 hours

delete branch facebook/hermes

delete branch : dependabot/npm_and_yarn/website/ssri-6.0.2

delete time in 6 hours

pull request commentfacebook/hermes

Bump ssri from 6.0.1 to 6.0.2 in /website

@dulinriley merged this pull request in facebook/hermes@0e5c462adf4d1585ddadf3bd3b99019ce71a0996.

dependabot[bot]

comment created time in 6 hours

pull request commentfacebook/hermes

Bump ssri from 6.0.1 to 6.0.2 in /website

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

dependabot[bot]

comment created time in 6 hours

push eventfacebook/hermes

dependabot[bot]

commit sha 0e5c462adf4d1585ddadf3bd3b99019ce71a0996

Bump ssri from 6.0.1 to 6.0.2 in /website (#498) Summary: Bumps [ssri](https://github.com/npm/ssri) from 6.0.1 to 6.0.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/npm/ssri/blob/v6.0.2/CHANGELOG.md">ssri's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/zkat/ssri/compare/v6.0.1...v6.0.2">6.0.2</a> (2021-04-07)</h2> <h3>Bug Fixes</h3> <ul> <li>backport regex change from 8.0.1 (<a href="https://github.com/zkat/ssri/commit/b30dfdb">b30dfdb</a>), closes <a href="https://github-redirect.dependabot.com/zkat/ssri/issues/19">https://github.com/facebook/hermes/issues/19</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/ssri/commit/b7c8c7c61db89aeb9fbf7596c0ef17071bc216ef"><code>b7c8c7c</code></a> chore(release): 6.0.2</li> <li><a href="https://github.com/npm/ssri/commit/b30dfdb00bb94ddc49a25a85a18fb27afafdfbb1"><code>b30dfdb</code></a> fix: backport regex change from 8.0.1</li> <li>See full diff in <a href="https://github.com/npm/ssri/compare/v6.0.1...v6.0.2">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~nlf">nlf</a>, a new releaser for ssri since your current version.</p> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=ssri&package-manager=npm_and_yarn&previous-version=6.0.1&new-version=6.0.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `dependabot rebase` will rebase this PR - `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `dependabot merge` will merge this PR after your CI passes on it - `dependabot squash and merge` will squash and merge this PR after your CI passes on it - `dependabot cancel merge` will cancel a previously requested merge and block automerging - `dependabot reopen` will reopen this PR if it is closed - `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/facebook/hermes/network/alerts). </details> Pull Request resolved: https://github.com/facebook/hermes/pull/498 Reviewed By: neildhar Differential Revision: D27856382 Pulled By: dulinriley fbshipit-source-id: 4676d4cc22f7e3786c9d45b41c653066d71b691d

view details

push time in 6 hours

PR closed facebook/hermes

Bump ssri from 6.0.1 to 6.0.2 in /website CLA Signed dependencies

Bumps ssri from 6.0.1 to 6.0.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/npm/ssri/blob/v6.0.2/CHANGELOG.md">ssri's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/zkat/ssri/compare/v6.0.1...v6.0.2">6.0.2</a> (2021-04-07)</h2> <h3>Bug Fixes</h3> <ul> <li>backport regex change from 8.0.1 (<a href="https://github.com/zkat/ssri/commit/b30dfdb">b30dfdb</a>), closes <a href="https://github-redirect.dependabot.com/zkat/ssri/issues/19">#19</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/ssri/commit/b7c8c7c61db89aeb9fbf7596c0ef17071bc216ef"><code>b7c8c7c</code></a> chore(release): 6.0.2</li> <li><a href="https://github.com/npm/ssri/commit/b30dfdb00bb94ddc49a25a85a18fb27afafdfbb1"><code>b30dfdb</code></a> fix: backport regex change from 8.0.1</li> <li>See full diff in <a href="https://github.com/npm/ssri/compare/v6.0.1...v6.0.2">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~nlf">nlf</a>, a new releaser for ssri since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

1 comment

1 changed file

dependabot[bot]

pr closed time in 6 hours

startedvegaluisjose/reticle-evaluation

started time in 7 hours

startedkhale/iit3503-starter

started time in 7 hours

pull request commentfacebook/hermes

Bump ssri from 6.0.1 to 6.0.2 in /website

@dulinriley has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

dependabot[bot]

comment created time in 8 hours

create barnchfacebook/hermes

branch : dependabot/npm_and_yarn/website/ssri-6.0.2

created branch time in 8 hours

PR opened facebook/hermes

Bump ssri from 6.0.1 to 6.0.2 in /website

Bumps ssri from 6.0.1 to 6.0.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/npm/ssri/blob/v6.0.2/CHANGELOG.md">ssri's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/zkat/ssri/compare/v6.0.1...v6.0.2">6.0.2</a> (2021-04-07)</h2> <h3>Bug Fixes</h3> <ul> <li>backport regex change from 8.0.1 (<a href="https://github.com/zkat/ssri/commit/b30dfdb">b30dfdb</a>), closes <a href="https://github-redirect.dependabot.com/zkat/ssri/issues/19">#19</a></li> </ul> <p><!-- raw HTML omitted --><!-- raw HTML omitted --></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/npm/ssri/commit/b7c8c7c61db89aeb9fbf7596c0ef17071bc216ef"><code>b7c8c7c</code></a> chore(release): 6.0.2</li> <li><a href="https://github.com/npm/ssri/commit/b30dfdb00bb94ddc49a25a85a18fb27afafdfbb1"><code>b30dfdb</code></a> fix: backport regex change from 8.0.1</li> <li>See full diff in <a href="https://github.com/npm/ssri/compare/v6.0.1...v6.0.2">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~nlf">nlf</a>, a new releaser for ssri since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

pr created time in 8 hours

issue commentfacebook/hermes

Can we load multiple hermes' bundles in a single VM?

@RajeshBatth Hey, did you find a way to solve that problem? I'm trying to load base bundle containing common features, and other bundles containing just logic code.

RajeshBatth

comment created time in 10 hours

push eventfacebook/hermes

Gijs Weterings

commit sha 696ddb5a704146f07f8fc06ea351e5fd61fd1c47

Change HermesRuntime::getExecutedFunctions to return a map for all runtimes Summary: The `HermesRuntime::getExecutedFunctions` call only returned information from the first runtime. We're interested in specific runtime(s), so in this diff I've modified the `getExecutedFunctions` method to return a map of `<string -> long[]>`. Reviewed By: dulinriley Differential Revision: D26050062 fbshipit-source-id: 255511c836f3021da9a137b12a298e4c9b63abbd

view details

Gijs Weterings

commit sha 9bc7450ad68a501ca07d0e7bb85e239fca709d44

Populate SegmentID based off SourceURL for classic bundles Summary: Given the build time regression preventing Hermes Modules to ship in debug builds in the near future (more info: https://fb.workplace.com/groups/684200151742597/permalink/1876367169192550), we need to break our dependency on this work for the Jest E2E coverage collection. Because the SegmentID isn't populated in classic builds, the API will return bogus data for us unless we're using Hermes Modules. To circumvent this, I've created a workaround in this diff that attempts to extract the SegmentID from the SourceURL. This is less than ideal obviously, but without it we cannot ship coverage collection for FB4a, which means we can't do landblocking test runs on React Native product changes. As the usage of Jest E2E is growing, this is causing increasingly large oncall loads for both us (Failing tests blocking OTA updates) and product teams (Oncall having to investigate, bisect and fix failures in the test). For that reason, I think it's worth putting this workaround in place until we have Hermes Modules rolled out successfully. Reviewed By: makovkastar Differential Revision: D27293987 fbshipit-source-id: 0090e30dc956ecfd375f496904351f48a6ca1a1b

view details

push time in 11 hours

MemberEvent

push eventfacebook/hermes

Neil Dhar

commit sha b800c101e85ff0d4ad8231b5b662d4209b9d1060

Add comment about runtime optimisation to CompileJS Summary: Runtime optimisations need to be enabled in order for CompileJS to actually optimise bytecode. Make this clear in the doc comment since it's easy to make this mistake. Also clean up an old comment about a task that has since been closed. Reviewed By: avp Differential Revision: D27829745 fbshipit-source-id: b93fdc42ea30c218899a9de9ed0f4e942aa4bcda

view details

push time in 3 days

push eventfacebook/hermes

Aakash Patel

commit sha 9cca7b6dc7590386dd36cf89051e6053c536b724

Use a handle in EXPECT_STRINGPRIM. Summary: Depending on argument evaluation order, `StringPrimitive::createNoThrow` could move the object that `x` points to. Avoid this by allocating `x` in a handle first, and then calling `createNoThrow` separately. Reviewed By: tmikov Differential Revision: D27827031 fbshipit-source-id: 5072787b67c05bec67a7156bcdc6e7b5ab558c4f

view details

push time in 3 days