Summary:
Constructing a `JSError` currently catches all exceptions that occur,
regardless of their type, and embeds the information from them in the
newly created `JSError`. This means that the type of exceptions can be
silently changed.
This results in a bug if Hermes is built with
`HERMESVM_EXCEPTION_ON_OOM` enabled. The OOM exception will get
converted to a `JSError`, which in turn can get converted into a
regular JS exception. The regular JS exception can then be caught by JS
and ignored. This leads to the VM continuing to execute in a bad
state.
I considered three ways to fix this:
1. Add a new type of exception to JSI that is intentionally meant to be
ignored, and the Hermes OOM exception then subclasses it.
2. Propagate all exceptions that happen when constructing `JSError`.
3. Propagate all exceptions except `JSIException`s when constructing
`JSError`.
The first is technically the most surgical, but it adds complexity to
JSI, and will require some extra machinery to implement since we
wouldn't be able to throw it directly from inside the VM. I'm also not
comfortable with the idea of JSI suppressing exceptions that are
completely unrelated to JSI.
The second is the simplest, and seems to match what JS would do if
`throw new Error()` itself threw, but there is some possibility that it
is a change in behaviour for existing code.
So the third approach, which is implemented in this diff, tries to
compromise between the two. Hermes can only ever throw `JSIException`s
from regular JS operations, so there should be no change for existing
code (except code that uses exceptions on OOM, which is what we're
trying to fix). Any other exception gets passed through to the caller.
Changelog:
[Internal][Fixed] - Fixed handling of Hermes OOM exceptions in JSI.
Reviewed By: jpporto
Differential Revision: D41831616
fbshipit-source-id: 42e0dde1c4acc016ab19533941c58fc1797ba1c2
Summary:
Many operations on references in JS can modify the referent by
executing additional JS, including operations that we currently mark as
const such as `getProperty`. Because of this, the current distinction
between const and non-const operations on references like `jsi::Object`
is somewhat arbitrary.
A more consistent approach is to mark all operations as const, so that
it is clear that the const-ness applies to the reference and not the
referent. This is analogous to how smart pointers work, since something
like `const shared_ptr<T>` only makes the pointer const, as opposed to
`shared_ptr<const T>`.
This also gives users better guarantees and more flexibility in where
these references may be used.
Changelog:
[General][Changed] - Mark methods on JSI references as const.
Reviewed By: fbmal7
Differential Revision: D41599116
fbshipit-source-id: 40b1537581b09c5a34d0928ee04e7db2b50d26ea
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
## Changelog:
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Throws a JS error instead of crashing Hermes with an invariant when trying to convert a JS symbol or BigInt to a folly::dynamic value.
Changelog:
[General][Fixed] - Fixed crash when converting JS symbol to folly::dynamic
Reviewed By: javache
Differential Revision: D40444164
fbshipit-source-id: 37df8059b2eb425563f30cf1e9c0436e8d665b34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
X-link: https://github.com/facebook/hermes/pull/793
Add a JSI API for constructing `ArrayBuffer`s from a user provided
`jsi::MutableBuffer`.
Changelog: [General][Added] Added ability to construct ArrayBuffers from existing memory buffers.
Reviewed By: jpporto
Differential Revision: D37744467
fbshipit-source-id: 9d9ece00d1dbde341846c45fa30c935b5fa81e9a
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
This change adds the following methods to jsi::BigInt
* [static] fromInt64(value): creates a jsi::BigInt from a signed 64-bit value
* [static] fromUint64(value): creates a jsi::BigInt from an unsigned 64-bit value
* [static] strictEquals(a, b): return a === b, a and b are BigInts
* asInt64(): truncates the BigInt to a single signed 64-bit integer; throws a JSIException if the truncation is lossy.
* getInt64(): truncates the BigInt to a single signed 64-bit integer
* isInt64(): returns true if the BigInt can be truncated losslessly to an int64_t
* asUint64(): truncates the BigInt to a single unsigned 64-bit integer; throws a JSIException if the truncation is lossy.
* getUint64(): truncates the BigInt to a single unsigned 64-bit integer
* isUint64(): returns true if the BigInt can be truncated losslessly to an uint64_t
* toString(radix): converts the BigInt to a string representing the number in the given radix.
A lossy truncation is one that yields a result from which the BigInt cannot be reconstructed from, i.e.,
* BigInt::fromInt64(b.toInt64()) !== b
* BigInt::fromUint64(b.toUint64()) !== b
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D37909139
fbshipit-source-id: 172848024f8367aed73cc602f38cde22f03cac8f
Summary:
Minor improvements to NativeState implementation and test. Does not change the API.
Changelog:
[Internal][Changed] - Minor improvements to jsi::NativeState
Reviewed By: neildhar
Differential Revision: D37961515
fbshipit-source-id: b87dcf2458ace883c784f3127a13f5a6c296d4a2
Summary:
Add API for setting/getting native state.
When present, the internal NativeState property of an object always stores a NativeState with a pointer to a heap-allocated shared_ptr + a finalizer that simply `delete`s it.
Changelog:
[Internal][Added] - JSI API for setting/getting native state on a JS object
Reviewed By: jpporto
Differential Revision: D36499239
fbshipit-source-id: a1ff1905811db1aac99ece3f928b81d0abfb342b
Summary:
`asHostObject` should throw a `JSINativeException` like the other `as*`
functions. This should be a safe change to make in most cases, since
this function already did not work when JSI was being provided by a
dynamic library. However, I defer to mhorowitz.
Changelog: [Fixed] Throw JSINativeException from asHostObject
Reviewed By: jpporto
Differential Revision: D36873355
fbshipit-source-id: 589ac50ebb4ecec4bacfd923d8b0795c0a6c0e34
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
The current implementation of `throwJSError` places it in jsi.cpp, but
does not actually export it. This means that when JSI is being provided
by a dynamic library, `detail::throwJSError` will not be available.
To fix this, move the definition of `throwJSError` into jsi-inl.h,
similar to all of the other functions in the `detail` namespace. This
uses a roundabout implementation of `throwJSError` in order to avoid
directly using `throw`, which would fail to compile when exceptions are
turned off.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D36873154
fbshipit-source-id: bbea48e0d4d5fd65d67a029ba12e183128b96322
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
The current JSI implementation is converting a Symbol to String when creating a jsi Value.
Changelog: [General][Fixed]
Reviewed By: neildhar
Differential Revision: D35705825
fbshipit-source-id: 3bee0a02bb77643c6a33031b4d98ac9a7e126303
Summary:
The `override` keyword was used for some overriden methods and was not
used for others. This caused the `-Winconsistent-missing-destructor-override`
warning to show up, and since in some cases we build with `-Werror`, this broke
the build.
This diff adds the missing `override` keyword in a few places.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: kodafb
Differential Revision: D35513149
fbshipit-source-id: 92bca699f1be163189487d50c1050402df2ff038
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
This Diff moves from specifying a list of files to use file(GLOB) with
CONFIGURE_DEPENDS on several CMakefiles.
I've updates those where we use globbing also inside buck.
Changelog:
[Internal] [Changed] - Setup Globbing with CONFIGURE_DEPENDS inside CMake files
Reviewed By: ShikaSD
Differential Revision: D34826311
fbshipit-source-id: 8fc654626c897cdc4cdd79c699ce19f1e5e1212f
Summary:
Rearranges folly_futures configuration into a static library only required for `hermes-inspector` + `folly_runtime` which merges `folly_json` and mutex-related implementations `folly_futures` was used for. As `hermes-executor-debug` is removed by `vmCleanup` configurations later, it allows to shave additional 300KB from the release APK size.
Changelog: [Internal] - Rearrange folly build to reduce APK size
Reviewed By: cortinico
Differential Revision: D34342514
fbshipit-source-id: b646680343e6b9a7674019506b87b96f6007caf2
Summary:
This is the first round of CMake files to support the React Native build on Android.
They're supposed to eventually replace the various Android.mk files we have around in the codebase.
So far we're not actively using them. This is the first step towards migrating our
setup to use CMake
Changelog:
[Internal] [Changed] - First Round of CMake files for React Android
Reviewed By: ShikaSD
Differential Revision: D34762524
fbshipit-source-id: 6671e203a2c83b8874cefe796aa55aa987902a3b
Summary:
Silence some warnings in xcode 13.3 by explicitly defining some copy constructors in JSI and adding a compiler flag in Hermes.
Changelog:
[Internal][Fixed] - Build issues
Reviewed By: jpporto
Differential Revision: D34526541
fbshipit-source-id: 7029e3d20b9209007cf7e9f4c935338513ee1dd0
Summary:
This is pre-work for adding the v8 stack trace API support.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D34048366
fbshipit-source-id: 9d2b469767f7669cb428c61b215f193894892c03
Summary:
Changelog:
[Internal][Fixed] - I have been reading this header file recently and discovered some typos
Reviewed By: kodafb
Differential Revision: D32455214
fbshipit-source-id: c27291943476014b787ee1641fd8642056bdbc5a
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Custom tags made with `VM_MAKE_TAG` are meant to be used to tag
anonymous mappings, and should be passed in as the file descriptor.
We can't use them for file backed mappings.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D29038256
fbshipit-source-id: 11324a3e798e695709d7d340e84e5fe6f7ffaad3
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
