Summary:
Fixes Xcode release builds when Hermes is enabled.
The Hermes debugger is loaded by the Hermes executor only if HERMES_ENABLE_DEBUGGER is defined. The hermes-engine Pod would set `HERMES_ENABLE_DEBUGGER=0` in release builds, but of course this would satisfy the HERMES_ENABLE_DEBUGGER ifdef check, leading to build time issues due to missing `hermes::debugger` symbols.
Now, both the `hermes-engine` and `React-hermes` pods only set `HERMES_ENABLE_DEBUGGER=1` in debug builds. No gcc preprocessor definition is added by these pods in release builds.
Changelog:
[iOS] [Changed] - Do not load Hermes inspector in release builds
Reviewed By: cipolleschi
Differential Revision: D40077503
fbshipit-source-id: dd9ce148e8521fc4e43e47e90f29ba8f7c9b7e4a
Summary:
This PR renames ` hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`, moves it to `packages/hermes-inspector-msggen` and makes the package private as part of RFC480.
Related to https://github.com/facebook/react-native/issues/34692
## Changelog
[General] [Changed] - Move and rename `hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`
Pull Request resolved: https://github.com/facebook/react-native/pull/34850
Test Plan: run `sh ReactCommon/hermes/inspector/tools/run_msggen`
Reviewed By: mattbfb
Differential Revision: D40060406
Pulled By: cortinico
fbshipit-source-id: e018fd88e8374a69fbd8737fbb9abe7565d4a003
Summary:
Cleans up the dependencies in `ReactCommon/hermes/inspector/tools/msggen` by
- Analyzing and removing any dependencies that are never referenced.
- Upgrading all dependencies to their latest versions (by deleting `yarn.lock` and re-running `yarn`).
- I only upgraded Babel dependencies to the same version used by the rest of `react-native`.
Notably, this resolves 13 vulnerabilities reported by Dependabot.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34782
Test Plan:
Ran the following successfully:
```
$ cd ReactCommon/hermes/inspector/tools/msggen
$ yarn
$ yarn test
$ yarn build
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D39804478
fbshipit-source-id: c673e80b64fcf49c3f903c5d7f0a68c77d63a4bd
Summary:
Upgrades all of our JavaScript tooling to use `yargs@^17.5.1`.
Of all [release notes](https://github.com/yargs/yargs/releases), these are the major version notes:
- [v17.0.0](https://github.com/yargs/yargs/releases/tag/v17.0.0)
- [v16.0.0](https://github.com/yargs/yargs/releases/tag/v16.0.0)
A cursory inspection suggests that these breaking changes are unlikely to seriously impact our use cases (or can be fixed forward).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D39550338
fbshipit-source-id: 5b2c5265f8c7a95ab0cc9bab62873f9e4355f32f
Summary:
We already support attaching-on-reload when a debugger was a previously connected, and this connection logic seems to slow down app startup by 2 seconds in debug mode when running on device.
Changelog:
[Internal][Removed]
Reviewed By: jpporto
Differential Revision: D39272704
fbshipit-source-id: deb8651798cb9a13b81e1703920d3f9bd58869d2
Summary:
A previous change made the RuntimeAdapter contain a HermesRuntime (as opposed to an arbitrary JSI Runtime).
Now that it's known to be a HermesRuntime, expose that type information to the Inspector, so a runtime type check can be skipped (which is failing in some builds, despite the concrete type being what's expected).
Changelog: [internal]
Reviewed By: neildhar
Differential Revision: D39429109
fbshipit-source-id: ad5ae0604ac208da2002fd37e38d24319b45aebd
Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## 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] [Fixed] - Fix hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5
Summary:
The `RuntimeAdapter` may be used after `disableDebugging` has been called. To ensure the `RuntimeAdapter` is alive long enough for this use, the Inspector should continue to control `RuntimeAdapter`'s lifetime (which is currently done via a `unique_ptr` that's moved into the Inspector).
Callers need a way to identify the `RuntimeAdapter` after it has been moved into the Inspector so that debugging can be disabled via `disableDebugging`.
This could be done by switching from a `unique_ptr` to a `shared_ptr` (so the caller can keep a copy), but consumers don't really have a reason to hang onto the `RuntimeAdapter` instance. Instead, leave the `RuntimeAdapter` inside a `unique_ptr`, and have consumers use a token to identify instances.
Update all consumers of this API to use this new token interface.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38513256
fbshipit-source-id: 33580747cd8365d25dbddbe289f0c41141e3bc6a
Summary:
Make the interface to enable/disable debugging symmetrical; both enabling and disabling are done by passing in a reference to the RuntimeAdapter.
Doing so requires moving ownership of the RuntimeAdapter, so each caller (java2js, arfx engine, React Native, react-native-github, and venice) has been updated to own their adapter.
Additionally, the two implementations of the Inspector connection (react-native-github and arfx engine) have been updated to expect and use the new argument.
`Connection::getRuntime` could be removed and replaced with calls to `Connection::getRuntimeAdapter::getRuntime`. I've left that choice to a followup diff, as this one is getting messy enough as it is.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38242964
fbshipit-source-id: f2a3354f9d424b203a76d2c15122a6515a0926f2
Summary:
Changelog: [Internal]
Debugging is enabled via `enableDebugging` with a `RuntimeAdapter` that provides a `HermesRuntime`. This same `HermesRuntime` should be passed to `disableDebugging`, not a decorated version. Change the argument type of `disableDebugging` to steer callers in the right direction.
Reviewed By: jpporto
Differential Revision: D38051662
fbshipit-source-id: ae436a4af12fa01143bfbcdb97e65e4fca90154d
Summary:
Changelog: [Internal]
Provide a `HermesRuntime` from the `RuntimeAdapter` (instead of a decorated Hermes runtime).
As the Inspector can now directly access the `HermesRuntime` (which exposes access to the debugger), `RuntimeAdapter::getDebugger` is no longer necessary; remove it.
Reviewed By: jpporto
Differential Revision: D38050821
fbshipit-source-id: fa83165a9348bdff0dce1b04ec1afb81d2b1c3e2
Summary:
Changelog: [Internal]
Make runtime use more consistent, always using the same undecorated runtime. This prevents the previous mixing of decorated and undecorated runtimes.
Reviewed By: jpporto
Differential Revision: D38035166
fbshipit-source-id: 81929e42ccc4de6d5c5c09ee7ee31f055af82735
Summary:
The RN Hermes Inspector keeps a mapping of pageId to
Connection. This mapping is created in the call to
enableDebugging. Later, when disableDebugging is invoked,
the inspector will iterate over the pageId to Connection map
to find which page to is being disabled.
The DecoratedRuntime enables debugging on construction, and
disables on destruction. When disabling debugging, the
DecoratedRuntime then passes the "naked" hermesRuntime,
which in turn gets checked against all connections' runtimes.
It turns our that ```HermesExecutorRuntimeAdapter::getRuntime```
returns the runtime **wrapped** by the DecoratedRuntime, and
not hermesRuntime itself.
This means that no connections match the request for
disabling debugging. Which means the Connection never
gets deleted, which in turns keep its underlying adapter (in
this case, the ```HermesRuntimeExecutorAdapter```) alive,
which has a shared_ptr to the runtime wrapped by the DecoratedRuntime.
Other than effectively leaking this connection (and thus the runtime),
this also causes an issue when the app tries to re-load the page -- at
which point the inspector will remove the old entry from the page to
connection mapping, thus initiating the destruction of the (leaked)
Runtime in a thread other than the thread that created the runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37809467
fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
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:
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:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Adds CMake files to configure hermes-executor build, with the same setup as we have in Android.mk
Changelog: [Internal] - CMake build config for hermes executor
Reviewed By: cortinico
Differential Revision: D34811909
fbshipit-source-id: 2df6dbaf46131db87a25e26c83b38ba44f29d1d3
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/33396
This commit fully unplugs the `ReactAndroid` from using hermes from the NPM package and plugs the usage of Hermes via the `packages/hermes-engine` Gradle build.
I've used prefab to share the .so between the two builds, so we don't need any extra machinery to make this possible.
Moreover, I've added a `buildHermesFromSource` property, which defaults to false when RN is imported, but is set to true when RN is opened for local development. This should allow us to distribute the `react-native` NPM package and users could potentially toggle which source to use (but see below).
Changelog:
[Android] [Changed] - Build Hermes from Source
Reviewed By: hramos
Differential Revision: D34389875
fbshipit-source-id: 107cbe3686daf7607a1f0f75202f24cd80ce64bb
Summary:
Fix a few issues with msggen:
1. run_msggen: fully-qualified path to clang-format
1. Updated the license for autogenerated files
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D34114718
fbshipit-source-id: 831d4b20bfdc39cfa1226e2a32dcb445c8086ff3
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Notifications
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34055503
fbshipit-source-id: 8c2dd1066ba2b68e395226f15954d303894d0365
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Responses
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34052619
fbshipit-source-id: d213ed41335b64bf3168a43ce043f2c57f05fc52
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Messages
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34042008
fbshipit-source-id: 3a074e9840706ca977ff86d050e67b0dcea5c7ef
Summary:
[Hermes][Inspector] Implement the CDP API for calling a function on an object.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D33722301
fbshipit-source-id: da26e865cf29920be77c5c602dde1b443b4c64da
Summary:
Calls to Inspector::evaluate() and Inspector::executeIfEnabled()
take a user-provided callback which are not try-guarded. This
means that, should the user code throw, the inspector's process
will likely die due to the unhandled exception. This change
makes sure that, if the user provided callback throws, then
the promise attached to those methods will be fulfilled by
an exception.
Change: [internal]
Reviewed By: avp
Differential Revision: D33852073
fbshipit-source-id: 7fbb6662b28d393a5d5b494c004aa9521e23ebb6
Summary:
Follow up to https://github.com/facebook/react-native/issues/32683 to also link hermes-inspector statically.
## Changelog
[Android] [Fix] - Static link for hermes-inspector
Pull Request resolved: https://github.com/facebook/react-native/pull/32694
Test Plan: Tested a clean build and made sure hermes-inspector.so doesn't exist anymore.
Reviewed By: cortinico
Differential Revision: D32791208
Pulled By: ShikaSD
fbshipit-source-id: 6076b263469b9e2c6176d488d13292d4f1731dcc
Summary:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here https://github.com/facebook/react-native/blob/b8f415eb6cdc0e0e7a7413b6f9defdcee304d9e8/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk#L20. There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368