Commit Graph

45 Commits

Author SHA1 Message Date
SachinTotale b8d6ef3726 Memory Leak due to JSStringRelease not called in multiple places in JSCRuntime.cpp (#25884)
Summary:
Memory Leak due to JSStringRelease not called in multiple places in JSCRuntime.cpp
Issue: https://github.com/facebook/react-native/issues/25664
Reproducible repo: https://github.com/bhandarijiwan/memory_issue_repro

## Changelog
[JSC] [JSCRuntime.cpp] - Added missing JSStringRelease calls in missing places
Pull Request resolved: https://github.com/facebook/react-native/pull/25884

Test Plan: Tested that is no memory leak with various NativeModule to JS call flows

Reviewed By: JoshuaGross

Differential Revision: D16928985

Pulled By: TheSavior

fbshipit-source-id: 65ce15ae32482d0db39bad7e22a2fed9ee04f230
2019-08-20 17:14:01 -07:00
James Treanor ca9e108110 Remove 's.static_framework = true' requirement for podspec (#25816)
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).

This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.

However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.

This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.

This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.

## Changelog

I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816

Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:

1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.

Reviewed By: hramos

Differential Revision: D16495030

Pulled By: fkgozali

fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 11:46:43 -07:00
James Treanor 8131b7bb7b CocoaPods frameworks compatibility: Step 2 (#25619)
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.

It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.

The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .

There are still a few breaking changes which I hope will be acceptable:

- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.

Still to do:

- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �

## Changelog

[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619

Test Plan:
### FB

```
buck build catalyst
```

### Sample Project

Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.

You can see that it works with these steps:

1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`

The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.

### RNTesterPods

`RNTesterPodsPods` can now work with or without `use_frameworks!`.

1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.

Reviewed By: PeteTheHeat

Differential Revision: D16465247

Pulled By: PeteTheHeat

fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-24 23:27:09 -07:00
Min ho Kim 84f5ebe4f9 Fix typos (#25770)
Summary:
Fix typos mostly in comments and some string literals.

## Changelog

[General] [Fixed] - Fix typos
Pull Request resolved: https://github.com/facebook/react-native/pull/25770

Differential Revision: D16437857

Pulled By: cpojer

fbshipit-source-id: ffeb4d6b175e341381352091134f7c97d78c679f
2019-07-23 03:23:11 -07:00
Riley Dulin c24387e45c Use UTF-8 instead of ASCII for setting object properties from folly::dynamic
Summary:
Based on Hermes Issue: https://github.com/facebook/hermes/issues/47
It was not actually a bug in Hermes, but a bug in JSI, assuming that all string property names from
`folly::dynamic` are ASCII.

Now we'll be more intentional and directly state `forUtf8` rather than the implicit ASCII encoding.

Reviewed By: mhorowitz

Differential Revision: D16347857

fbshipit-source-id: 6bcfbf9f918dc0a7a485b88a1b537d6c2dd322cc
2019-07-17 17:05:47 -07:00
Riley Dulin 96be82e3f9 clang-format everything
Summary: Ran clang-format on all of JSI.

Reviewed By: mhorowitz

Differential Revision: D16347858

fbshipit-source-id: 004afde1944f60a2c0989a7c38d5b3c58587f1cb
2019-07-17 17:05:46 -07:00
James Treanor 6ef91061e8 CocoaPods frameworks compatibility: Step 1 (#25496)
Summary:
This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries.

I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884.

These are the changes:

- Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures.
- Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does.
- Adding some missing dependencies to fix undefined symbols errors.
- Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing.

## Changelog

[iOS] [Fixed] - Updated podspecs for improved compatibility with different install types.
Pull Request resolved: https://github.com/facebook/react-native/pull/25496

Test Plan:
Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed.

You can see that it works with these steps:

1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout podspec-updates`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`

The sample app will build and run successfully.

Reviewed By: mmmulani

Differential Revision: D16167346

Pulled By: fkgozali

fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 10:21:38 -07:00
Ashok Menon 424f93022d Use iosfwd instead of iostream
Summary:
The instrumentation header only needs the forward declarations for ostream, so
we can use just include `iosfwd`, as suggested by Riley in an earlier diff.

Reviewed By: kodafb

Differential Revision: D16152451

fbshipit-source-id: 2afbc40e623b180dfc5917fc8093ab15bf647968
2019-07-08 14:56:44 -07:00
Ashok Menon 14686259d9 Create Snapshot From Stream
Summary:
Adding an instrumentation endpoint that allows us to write a snapshot out to an
arbitrary output stream.  This is in addition to `createSnapshotFromFile`.  I
reserve the right to replace the latter with the former in a later diff.

This is necessary to allow snapshots to be requested over the chrome debugger
protocol.  The protocol sends the snapshot over the wire in chunks so we need
to be able to use an output stream that can do the chunking.

Because LLVM types are not available at the JSI layer, we accept a
`std::ostream` reference which we wrap with `llvm::raw_os_ostream` within
Hermes.  We should not incur the static initializer cost (or other code bloat)
of using ostreams as a result.

Reviewed By: cwdick

Differential Revision: D16016319

fbshipit-source-id: 2d0b4848fd5cbe9ddee371d856cd8eb19dd80396
2019-06-28 06:15:33 -07:00
Ashok Menon bbf093a03b Remove const_cast in createSnapshotFromFile wrapper.
Summary:
The function is not annotated with `const` so `plain()` will return a non-const
reference to the undecorated Runtime already.  Seems like the const_cast was a
hold-over from a previous iteration.

Reviewed By: mhorowitz

Differential Revision: D16016320

fbshipit-source-id: 3dfa1e9acf2fc5c1ad61c9a8cd27c3c2e42036d3
2019-06-27 10:02:26 -07:00
Rain ⁣ 14f249178e standardize C-like MIT copyright headers throughout fbsource
Summary:
`/*` is the standard throughout open source code. For example, Firefox uses single /*: https://hg.mozilla.org/mozilla-central/file/21d22b2f541258d3d1cf96c7ba5ad73e96e616b5/gfx/ipc/CompositorWidgetVsyncObserver.cpp#l3

In addition, Rust considers `/**` to be a doc comment (similar to Javadoc) and having such a comment at the beginning of the file causes `rustc` to barf.

Note that some JavaScript tooling requires `/**`. This is OK since JavaScript files were not covered by the linter in the first place, but it would be good to have that tooling fixed too.

Reviewed By: zertosh

Differential Revision: D15640366

fbshipit-source-id: b4ed4599071516364d6109720750d6a43304c089
2019-06-06 19:40:32 -07:00
zhongwuzw 68bca1fbd0 Excluded tests file from JSI pod (#25151)
Summary:
Tests file exposed in https://github.com/facebook/react-native/commit/608b1b5ea2d9861816aaf3c4289e4316d9304b87. This break e2e tests, so let's excluded them from JSI pod.

## Changelog

[iOS] [Fixed] - Excluded tests file from JSI pod
Pull Request resolved: https://github.com/facebook/react-native/pull/25151

Differential Revision: D15645046

Pulled By: cpojer

fbshipit-source-id: 19c712e4307cf712b8377d721661a2b476151732
2019-06-05 05:12:19 -07:00
Will Holen 608b1b5ea2 Include testlib files in JSI
Summary: This adds the testlib.cpp/h files to external JSI. They're in a `test/` subdirectory so that build scripts using globs like `*.cpp` won't include them.

Reviewed By: mhorowitz

Differential Revision: D15582281

fbshipit-source-id: 1785ee5071fcf98e92fbf3a11eddb21fe84b3799
2019-06-04 14:40:39 -07:00
Dmitry Dushkin b79d7db9db Consistent reporting native module name on crash on native side (#24741)
Summary:
_Reopened PR_ https://github.com/facebook/react-native/pull/24704#issuecomment-490017599
PR https://github.com/facebook/react-native/pull/24633 introduced some inconsistency in crash messaging, this PR fix it. Asked by mhorowitz

[General] [Added] - Consistent reporting native module name on crash on native side
Pull Request resolved: https://github.com/facebook/react-native/pull/24741

Differential Revision: D15242415

Pulled By: cpojer

fbshipit-source-id: 8346ffd7c74070ec676aa006c9791a4729946204
2019-05-07 14:57:20 -07:00
Zeyad Salloum fdd8fadea8 Revert D15237424: [react-native][PR] Consistent reporting native module name on crash on native side
Differential Revision:
D15237424

Original commit changeset: ded8db45b2a2

fbshipit-source-id: 99d176e1ee796dbbe9957eda08992a8a76ba109b
2019-05-07 02:48:14 -07:00
Dmitry Dushkin d6c33f915d Consistent reporting native module name on crash on native side (#24704)
Summary:
PR https://github.com/facebook/react-native/pull/24633 introduced some inconsistency in crash messaging, this PR fix it. Asked by mhorowitz

[General] [Added] - Consistent reporting native module name on crash on native side
Pull Request resolved: https://github.com/facebook/react-native/pull/24704

Differential Revision: D15237424

Pulled By: cpojer

fbshipit-source-id: ded8db45b2a2ec9998ff33fdbecef3f12c19578f
2019-05-07 02:15:58 -07:00
Dmitry Dushkin 6ab249f220 Report native module name on crash when native module has failed to load (#24633)
Summary:
After upgrading RN from 0.57 to 0.59.4 we've received a lot of crash reports like `Exception in HostObject::get: <unknown>`  with no clue what native module caused the crash. This commit adds native module name on crash in this situations. Related to https://github.com/facebook/react-native/issues/24607.

[General] [Added] - Report native module name on crash when native module has failed to load
Pull Request resolved: https://github.com/facebook/react-native/pull/24633

Differential Revision: D15120225

Pulled By: cpojer

fbshipit-source-id: cf8e3e5953548a58f1d010eb70343da5ee946ae8
2019-04-29 03:36:17 -07:00
zhongwuzw e240ac0dc6 Update jsi podspec to support new directory structure (#24388)
Summary:
Related https://github.com/facebook/react-native/commit/094f221a0c2d24f16a9540e4f176783843ec4fd9, restructure the jsi directory, so update the podspec file either.

cc. shergin cpojer

[iOS] [Fixed] - Update jsi podspec to support new directory structure
Pull Request resolved: https://github.com/facebook/react-native/pull/24388

Differential Revision: D14869999

Pulled By: cpojer

fbshipit-source-id: 0a5df7e2ad83702c0498b2f70072735accc7f54c
2019-04-10 03:45:17 -07:00
Will Holen 5e5439a921 Update JSI from upstream
Summary: This change synchronizes the JSI API with its upstream, aiming to make this easier to automate in the future.

Reviewed By: mhorowitz

Differential Revision: D14783311

fbshipit-source-id: c180d0f728afbeb87a3e8e7331a39c06e73b907e
2019-04-09 11:44:32 -07:00
Will Holen 094f221a0c Move JSI source files into a separate directory
Summary: This will simplify updating the JSI API from upstream in the future.

Reviewed By: mhorowitz

Differential Revision: D14762674

fbshipit-source-id: fa4a86f08425943e301da4ef3df9893ebaa1493e
2019-04-09 11:44:32 -07:00
Marc Horowitz dcc40a6267 JSI es6 Symbol impl for JSCRuntime
Summary: this is an empirical hack

Reviewed By: fkgozali

Differential Revision: D14216647

fbshipit-source-id: 577ffb555c6e2f5a6456ccea5dff8e6ec757f80f
2019-03-21 13:33:32 -07:00
Marc Horowitz 7ccec333e9 sync with upstream jsi
Reviewed By: willholen

Differential Revision: D14232752

fbshipit-source-id: 2548158f2c2c8aa6e15656ef346d92d3c0937c4a
2019-03-21 13:33:32 -07:00
Jacob Bower b7c2c82c89 Thread through-return value from evaluateJavaScript()
Summary: Pass return value through to JSI layer.

Reviewed By: mhorowitz

Differential Revision: D14118187

fbshipit-source-id: 7e44c7dc335fd19d7c0aa1edb5be72ebea7eb851
2019-03-20 23:09:54 -07:00
ericlewis 97e6ea1371 Fabric: working podspecs & works in RNTester (#23803)
Summary:
This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera.

The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks.

- Yarn Install
- Uncomment the commented out pods in RNTester's pod file
- Open RNTesterPods workspace
- Run App

- this is only for pods, the non-pod RNTester will no longer work until updated with fabric too.
- `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is:
   1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called.
   2. Add observer for `RCTJavaScriptDidLoadNotification`
   3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`.

[General] [Added] - Use Fabric in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23803

Reviewed By: shergin, mdvacca

Differential Revision: D14450726

Pulled By: fkgozali

fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
2019-03-15 23:59:22 -07:00
ericlewis 28ceb0ad0b Fabric: support building for 32bit archs (#23915)
Summary:
Adds support for building on 32bit platforms, unlocking release mode for Xcode 💯

[General] [Added] - Fabric: 32bit support
Pull Request resolved: https://github.com/facebook/react-native/pull/23915

Differential Revision: D14460600

Pulled By: shergin

fbshipit-source-id: ebc487546aac05d3272ae095ac321ef58f2271f6
2019-03-14 10:14:36 -07:00
ericlewis 58c3a4c078 Fix crash when calling substring() on a string containing emoji. (#23609)
Summary:
Fixes #23459. It is not legal to write the character array of a std::string, and can result in undefined behavior.

[General] [Fixed] - Crash when substring intersects with emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/23609

Differential Revision: D14198159

Pulled By: mdvacca

fbshipit-source-id: 71060b1b99ddab89793c98c09f99ec9974479e62
2019-03-01 00:57:00 -08:00
Ville Immonen 2321b3fd7f Split React.podspec into separate podspecs for each Xcode project (#23559)
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.

The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.

*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)

[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559

Differential Revision: D14179326

Pulled By: cpojer

fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-21 18:35:44 -08:00
empyrical ff588b5087 JSI: Minor tweaks for building on MSVC (#23492)
Summary:
This is a re-submit of #23367, which was accidentally over-written in this commit:

https://github.com/facebook/react-native/commit/0d7faf6f73b942126e1f45016cde8fd480fd0164

This pull request makes this change to `jsi.h`:

 * Tweak the call to constructor `Pointer(Runtime::PointerValue* ptr)` in the constructor for `PropNameID`. I am not sure why MSVC wasn't working with the original version, but it compiles after I tweak that.

[General] [Fixed] - Tweaked `jsi.h` to build on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23492

Differential Revision: D14151511

Pulled By: hramos

fbshipit-source-id: 52d726d7b978d321a0343566ee527f2ec25e93f8
2019-02-20 10:12:12 -08:00
Peter Ammon 0d7faf6f73 Introduce prepareJavaScript jsi API
Summary:
This adds a new jsi API prepareJavaScript. This accepts the same
parameters as evaluateJavaScript() but does not evaluate anything; instead
it returns a new object PreparedJavaScript which can itself be evaluated,
via the new API evaluatePreparedJavaScript().

There is a new empty class PreparedJavaScript which may be subclassed by
each Runtime variant to store its particular prepared form.

Reviewed By: mhorowitz

Differential Revision: D10491585

fbshipit-source-id: 702b9e23f2ff03d71a8ab17efb7e154b16dd8e87
2019-02-15 01:52:00 -08:00
Peter Ammon 7a8957c0be evaluateJavaScript to accept a shared_ptr instead of unique_ptr
Summary:
This changes jsi::evaluateJavaScript() to accept a
const shared_ptr<Buffer> & instead of a unique_ptr<Buffer.

It is reasonable to want to pass the same buffer to evaluateJavaScript()
multiple times. This will also help unify the API with the upcoming
prepareJavaScript() API.

Because shared_ptr has a unique_ptr constructor, this is compatible with
all call sites.

Reviewed By: mhorowitz

Differential Revision: D14001664

fbshipit-source-id: b7a0b7ec578a3fd6a6272241d50067269d2b03e4
2019-02-15 01:52:00 -08:00
Jonathan Kim c02f278d8f xplat// -> fbsource//xplat/ for xplat/js
Reviewed By: scottrice

Differential Revision: D14076351

fbshipit-source-id: f803d2af438a5eb3f18c981793e17b6293d8ef1c
2019-02-14 23:53:32 -08:00
empyrical 78be6efda9 JSI: Minor tweaks for building on MSVC (#23367)
Summary:
This pull request makes two minor changes to `jsi.h`:

 * Tweak the `JSI_EXPORT` macro to automatically set itself to an empty value if `_MSC_VER` is defined - like how was done by acoates-ms [here](https://github.com/facebook/react-native/blob/8beb4bb58ab93af8c95af6844230d62c85ccab78/ReactCommon/cxxreact/JSBigString.h#L15-L21).
 * Tweak the call to constructor `Pointer(Runtime::PointerValue* ptr)` in the constructor for `PropNameID`. I am not sure why MSVC wasn't working with the original version, but it compiles after I tweak that.

[General] [Fixed] - Tweaked `jsi.h` to build on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23367

Differential Revision: D14032507

Pulled By: cpojer

fbshipit-source-id: 701c13e3509cc244dbe0c15f92067fae4382bee2
2019-02-11 15:42:18 -08:00
Matt Hargett 36916ee99d Fix portability issues to Linux, FreeBSD, and older libc++
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/21764

Differential Revision: D13902907

Pulled By: hramos

fbshipit-source-id: 640cde865b1bcc5ca43c17d00574b8e2f78ceaf4
2019-01-31 17:45:20 -08:00
Rafael Lincoln ac90c4fd6d Fix warnings in JSI (#23201)
Summary:
His PR is related to #22609

There are still some warnings related to folly, but I plan to make the correction and send the PR to the repo of the folly.

Changelog:
[IOS][Changed] - Fix warning in JSCRuntime
Pull Request resolved: https://github.com/facebook/react-native/pull/23201

Differential Revision: D13859393

Pulled By: cpojer

fbshipit-source-id: 95df2b76b28b460f890d11e1395fddb6b1cc8fed
2019-01-29 03:31:50 -08:00
Anandraj Govindan 1d0404c4e8 Making JSI_EXPORT macro definition conditional (#22561)
Summary:
This change enables defining the macro at a more global and central location. And thereby allowing us to building this file using MSVC.
Pull Request resolved: https://github.com/facebook/react-native/pull/22561

Reviewed By: fkgozali

Differential Revision: D13529762

Pulled By: RSNara

fbshipit-source-id: c78abb26f47aba25d50305c5bc0b23b6568f1243
2018-12-27 07:29:53 -08:00
Marc Horowitz 3f0f25f73c Back out "Check for thread consistency in JSCRuntime"
Summary:
This check is too aggressive.  We will consider putting it back once we are
more certain nothing will trigger it.

Differential Revision: D13350907

fbshipit-source-id: 6033bdbfe7adb2a18bdf889c090cf271497605e5
2018-12-05 16:59:31 -08:00
Marc Horowitz bdb084e8a8 Check for thread consistency in JSCRuntime
Summary:
In the version of JSC on iOS 11, creating a JSContext on one
thread and using it on another can trigger subtle and nearly
impossible to debug reentrancy-related crashes in the VM (see
https://bugs.webkit.org/show_bug.cgi?id=186827).  In !NDEBUG builds,
check for this case and throw an exception, so it can be detected
early.

Reviewed By: amnn

Differential Revision: D13313264

fbshipit-source-id: ee85435c20e23c8520495ce743d2f91f2eeada5c
2018-12-04 12:01:59 -08:00
Marc Horowitz bf2500e38e Switch to synchronous strategy for unprotect
Summary:
Older versions of JSC (ios 11 and before) have a bug which I
believe the ProtectionQueue mechanism tickles:
https://bugs.webkit.org/show_bug.cgi?id=186827

This removes the ProtectionQueue and replaces it with an atomic flag
to avoid calling unprotect after VM shutdown.

This also fixes a race condition in shutdown.

Reviewed By: danzimm

Differential Revision: D12969953

fbshipit-source-id: fa3a14f3207be67a987ac3cf0fc1c9ce88837b0b
2018-11-08 17:08:56 -08:00
Tim Yung a689711f68 RN: Missing Copyright Headers
Summary: Adds copyright headers to all files that are missing them.

Reviewed By: hramos

Differential Revision: D12837494

fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
2018-10-31 01:37:26 -07:00
Marc Horowitz 5d38264f9e Make SystemJSC on macosx actually use the system JSC framework
Reviewed By: mzlee

Differential Revision: D10475231

fbshipit-source-id: 67f6859cf93aa4fb91c174ee222694271c0d72ed
2018-10-26 17:08:04 -07:00
Marc Horowitz 2a44054e99 Refactor shutdown so that debug asserts can pass
Summary:
We were not accounting for shutdown properly when counting
jsi Objects at shutdown.

Reviewed By: danzimm

Differential Revision: D10451732

fbshipit-source-id: 7f0eb357aa3a011b7b2a97e44c22549e06e311c5
2018-10-26 17:08:04 -07:00
Héctor Ramos 47fb387455 Update copyright headers
Summary: Use MIT License copyright headers in JSI source code.

Reviewed By: axe-fb

Differential Revision: D10454031

fbshipit-source-id: d584073bb885fb7d977df1a45a6666ef6f52dcd6
2018-10-19 11:08:57 -07:00
Marc Horowitz 6370b86c1f Get RNTester to compile and run
Summary:
This diff includes a few changes:
1. Move the headers inside `jsiexecutor` into `jsiexecutor/jsireact`. As far as I'm aware, the Android ndk build system isn't flexible enough to support header namespaces, so we can't just expose the headers inside the `jsiexecutor` directory under the `jsireact` namespace. Therefore, I moved the headers to `jsiexecutor/jsireact`, and added `jsiexecutor` to the header search path.  This was the easiest way to simulate `jsireact` namespace.
2. Setup the Android.mk files to get RNTester compiling and running.
3. Introduce a `jscexecutor` module to make `JSCExecutor.java` execute without throwing.

**Note:** Moving the header files inside `jsiexecutor` probably breaks the iOS builds and internal builds. I'll fix those in subsequent diffs on this stack.

Reviewed By: shergin

Differential Revision: D9995429

fbshipit-source-id: 418a4ee91f585842c5e317af2f300227a51e9ba8
2018-10-18 01:06:24 -07:00
Marc Horowitz a23fb1a22c Add JSI implementation for JSC
Summary:
This diff is an implementation of jsi::Runtime which uses JSC as the virtual machine.  All of the JSC-specific details are encapsulated here.
@public

Reviewed By: RSNara

Differential Revision: D9328242

fbshipit-source-id: be3c7bed161916c1cb9a48182600b558f054eadc
2018-10-18 01:06:24 -07:00
Marc Horowitz e337bcafb0 Add JSI API and JSIDynamic glue to OSS React Native
Summary: This will help abstract the JS engine from React Native

Reviewed By: hramos

Differential Revision: D9328237

fbshipit-source-id: 7b34f55f28e43d83ba24d22e83e836c92ca737a9
2018-10-18 01:06:23 -07:00