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:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Summary:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Summary:
This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See https://github.com/facebook/react-native/pull/33381.
The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers.
Tested in the YogaKitSample, and also in a react-native app.
Changelog:
[iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus
X-link: https://github.com/facebook/yoga/pull/1150
Reviewed By: dmitryrykun
Differential Revision: D36966687
Pulled By: cortinico
fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39
Summary:
Ideally, the application should always be able to create the TurboModule object given an ObjC class. This debugging information will help track down these classes of issues, when they surface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D35945399
fbshipit-source-id: 1621a4a64bc8fb0411123fb1470bbb52ccf0edcf
Summary:
During the TurboModule init path, the TurboModuleManager asks the application to create the TurboModule object, given its class.
If the application is unable to create the TurboModule object, what should we do?
0. **What we do now:** Continue executing TurboModule init path.
1. Silently return nil early.
2. Silently return nil early, and RCTLogError.
If we Continue executing the TurobModule init path, we'll run into a segfault, because we'll call objc_setAssociatedObject(nil, ...).
This diff prevents that segfault, by doing a silent return of nil.
Changelog: [iOS][Fixed] - Prevent Nullptr segfault in TurboModule init path
Reviewed By: fkgozali
Differential Revision: D35942323
fbshipit-source-id: 7755800379c4bc733502314f3af3f401e9b04872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33688
These methods used to be public in the legacy implementation, and hiding them significantly reduces amount of customization available to other clients outside Fabric core.
Changelog: [Internal] Allow external callers to call UIManager methods
Reviewed By: cipolleschi
Differential Revision: D35818114
fbshipit-source-id: 4dc4177c82b5db9ae3d136a1a83f5ec3123b971f
Summary:
Minimal set of changes to intercept events in external modules. Current intended use-case is for Reanimated to handle events for the Animated properties.
Changelog: [Added] Add listeners to allow intercepting events in C++ core.
Reviewed By: cipolleschi
Differential Revision: D35312534
fbshipit-source-id: ec924b57fd0c0dabf7be7b886dbef23bf3170d6c
Summary:
Ensures that transaction telemetry modified by transaction controller is the same as sent in the view callbacks.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D35827347
fbshipit-source-id: 123ae01d4a7fe1a9c97ebccae3ae248f7f2cf654
Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.
This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.
One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.
Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.
In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.
## Changelog
[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects
Pull Request resolved: https://github.com/facebook/react-native/pull/33510
Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)
Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.
Reviewed By: cipolleschi
Differential Revision: D35214478
Pulled By: ShikaSD
fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
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:
Problem:
Current creation of ModuleConfig does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Fix:
Use std::move semantics to avoid copy of folly::dynamic, thus avoiding memory allocations.
## Changelog
[General] [Fixed] - Avoid full copy of large folly::dynamic objects by switching to std::move semantics
Pull Request resolved: https://github.com/facebook/react-native/pull/33621
Test Plan:
Compiled React Native for Windows
Consumed into Microsoft Excel App
Tested functionality through Microsoft Office Excel App
Viewed Memory Allocations in Debugger
Reviewed By: cortinico
Differential Revision: D35599759
Pulled By: RSNara
fbshipit-source-id: 095a961422cca4655590d2283f6955472f1f0410
Summary:
I guess it's the same since we're working on a `bool` but... this causes some compilation error.
Changelog:
[General][iOS] - Fix compilation warning in yoga
Reviewed By: Andrey-Mishanin
Differential Revision: D35438992
fbshipit-source-id: 22bb848dfee435ede66af0a740605d4618585e18
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
Distiller
Distiller
Distiller
Distiller
Distiller
Distiller
Distiller
Janic DuplessisandThibault Malbranche
Distiller
Sparsha SahaandLorenzo Sciandra
Distiller
Distiller
Distiller
Distiller
Kudo Chienandfortmarek
Distiller
Distiller
Distiller
Distiller
Nicola Corti
Distiller
Distiller
Distiller
Sam ZhouandFacebook GitHub Bot
Baoshuo RenandFacebook GitHub Bot
Ramanpreet NaraandFacebook GitHub Bot
Oleksandr MelnykovandFacebook GitHub Bot
MaeIgandFacebook GitHub Bot
Krzysztof MagieraandFacebook GitHub Bot
Richard HowellandFacebook GitHub Bot
Anand BashyamandFacebook GitHub Bot
John PortoandFacebook GitHub Bot
NikoAriandFacebook GitHub Bot
Hugo CuvillierandFacebook GitHub Bot
Alex LandauandFacebook GitHub Bot
Vincent RiemerandFacebook GitHub Bot
