5 of 6 standards met
Bug Description throws when passed a argument on Android. The same code works correctly in V8 (Chrome) and SpiderMonkey (Firefox). [x] I have run and confirmed this bug does not occur with JSC [x] The issue is reproducible with the latest version of React Native. Hermes git revision (if applicable): bundled with React Native 0.81.5 React Native version: 0.81.5 OS: Android Platform: arm64-v8a Steps To Reproduce 1. Create a React Native app with Hermes enabled (default for RN 0.81.5) 2. Run on an Android device or emulator 3. Execute any of the following: The crash occurs regardless of whether the is created via the constructor or a bigint literal (), and regardless of whether a locale argument is provided. Workaround: The Expected Behavior All three expressions should return without throwing, as is a valid argument per ECMA-402 and works correctly on V8 and SpiderMonkey. Related open issues: #1317 โ can't always display sign #789 โ truncates currency sign on Android
and called on their argument, which rejected BigInt with "Cannot convert BigInt to number". Per ECMA-402, both methods must accept BigInt. Changes : Replaced with in both and . Added shared helper for Number/BigInt handling. For BigInt inputs, conversion to is now validated to be exact: non-finite conversion results are rejected, round-trip check () is used to detect precision loss, imprecise conversions throw instead of silently rounding. : Removed try/catch that masked failures. Added coverage for positive, negative, and zero BigInt inputs to both and . Added regression checks that large imprecise BigInt values (e.g. ) throw for both APIs. This keeps BigInt accepted where possible while avoiding silent precision loss in the platform formatting layer. Original prompt This section details on the original issue you should resolve* Intl.NumberFormat.format() throws "Cannot convert BigInt to number" when passed a bigint on Android ## Bug Description throws when passed a argument on Android. The same code works correctly in V8 (Chrome) and SpiderMonkey (Firefox). [x] I have run and confirmed this bug does not occur with JSC [x] The issue is reproducible with the latest version of React Native. Hermes git revision (if applicable): bundled with React Native 0.81.5 React Native version: 0.81.5 OS: Android Platform: arm64-v8a ## Steps To Reproduce 1. Create a React Native app with Hermes enabled (default for RN 0.81.5) 2. Run on an Android device or emulator 3. Execute any of the following: The crash occurs regardless of whether the is created via the constructor or a bigint literal (), and regardless of whether a locale argument is provided. Workaround: ## The Expected Behavior All three expressions should return without throwing, as is a valid argument per ECMA-402 and works correctly on V8 and SpiderMonkey. Related open issues: facebook/hermes#1317 โ can't always display sign facebook/hermes#789 โ truncates currency sign on Android Investigate this bug in Intl (it has been reproduced on Android and MacOS, and likely is everywhere) and fix it. ## Comments on the Issue (you are @copilot in this section) Fixes facebook/hermes#1928 โจ Let Copilot coding agent set things up for you โ coding agent works faster and does higher quality work when set up for your repo.
Repository: facebook/hermes. Description: A JavaScript engine optimized for running React Native. Stars: 10816, Forks: 738. Primary language: JavaScript. Languages: JavaScript (54.4%), C++ (35.1%), C (4.5%), Rust (2.5%), TypeScript (0.9%). License: MIT. Latest release: v0.13.0 (1y ago). Open PRs: 62, open issues: 124. Last activity: 30m ago. Community health: 87%. Top contributors: avp, neildhar, micleo2, lavenzg, tmikov, kodafb, Huxpro, mhorowitz, jpporto, tsaichien and others.
Last 12 weeks ยท 265 commits
Per ECMA-402 ยง15.5.4, BigInt is a valid argument to NumberFormat format and formatToParts methods. Previously these called toNumber_RJS() which throws TypeError on BigInt inputs. Replace toNumber_RJS() with toNumeric_RJS() and, when the result is a BigInt, convert it to a decimal string via bigint::toString() and pass it through new string-based format/formatToParts overloads on each platform backend (ICU stub, Apple via NSDecimalNumber, Android via java.math.BigDecimal). This preserves exact precision for arbitrarily large BigInts. Fixes #1928
Summary Add support to for ESLint v10. 1. Added support for . Since this scope manager is heavily based on typescript-eslint's scope manager, I followed their changes in https://github.com/typescript-eslint/typescript-eslint/pull/11914 to ensure it was correct. Also followed their unit test changes. 2. Added to 's peer dependencies as optional, for documenting supported versions. I chose a fairly wide range since the ESLint parser interface hasn't changed much. Could maybe even lower the floor to v4 since that's the first changelog I see mention changes to parsers, but I don't know for sure. Also moved to since it's not required by the published code. 3. Migrated the internal eslint config to the flat config instead of eslintrc. Several incompatible plugins were swapped out for their updated forks (ft-flow and eslint-comments). Upgraded the internal eslint version to v9. Cannot go to v10 because some plugins use APIs not available in v10 (e.g. ). For example, https://github.com/flow-typed/eslint-plugin-ft-flow/pull/71 recursively needs to be upgraded first. Installed as a defensive measure: eslint v10 will require this to be installed. 4. Updated README of with flat config example. Note: it would be nice to see https://github.com/facebook/hermes/pull/1651 merged, since these packages published on npm do not display links to this repository, so it took me a minute to find this. Test Plan Ran the following commands: Build, test, and lint passes.
Related to https://github.com/facebook/react-native/issues/55913 Bug Description When running more than one Hermes Runtime in a React Native app, the extra runtimes may throw exceptions that could bubble up to the React Native's event loop and to be handled there. This can lead to crashes when the handling of the error is finished when invoking the deconstructor of the because its host runtime might have been already deconstructed. This sometimes manifests in as there are cases where the thread deconstructing the Hermes Runtime is a different than the one handling the exception. While we try to add try-catch safe-guards for all our API calls there are paths where the user might get just raw pointer to the and bypass them. A reproduction is available in the issue I linked above. Minimalistic reproduction would look something like this: While the above code makes little sense, I'm wondering if shouldn't actually be either runtime-agnostic (not tracked by the garbage collector) not exactly related to in JavaScript.