Adam Gleitman b4bbd398b4 Merge from upstream through 2020-09-30 (#833) ... * Fix initial padding value for TextInput Summary: Changelog: [internal] # Problem Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}. If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0. # Fix To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding. Reviewed By: JoshuaGross Differential Revision: D23731498 fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307 * Fabric: Simplifying ShadowTreeRevision implementation Summary: The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D23725688 fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce * Fabric: Using ShadowTreeRevision inside ShadowTree to store current commited tree Summary: Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable). Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D23725690 fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329 * Fabric: Introducing `ShadowTree::getCurrentRevision()` Summary: Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff). Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross, sammy-SC Differential Revision: D23725689 fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166 * Fabric: Removing shared_ptr from ShadowTreeCommitTransaction's argument Summary: We don't need a shared_ptr here and without it the code will be faster and simpler. This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross, sammy-SC Differential Revision: D23725687 fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768 * Fabric: Using `thread_local` keyword instead on own implementation in TransactionTelemetry Summary: Apparently, there is C++ keyword for this. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D23754284 fbshipit-source-id: 5f9bbcc72d9c586173624869d614f12d2319fb7b * Add an explicit NDK version to Android template (#29403) Summary: Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically. ## 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 --> [Android] [Added] - Add an explicit NDK version to Android template Pull Request resolved: https://github.com/facebook/react-native/pull/29403 Test Plan: Template builds as it should. NDK version gets installed with initial Android set up. Reviewed By: passy Differential Revision: D23752007 Pulled By: fkgozali fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf * Fabric: Removing `RCTCGColorRefUnretainedFromSharedColor()` Summary: This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make. Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer. Reviewed By: JoshuaGross Differential Revision: D23753509 fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6 * Fabric: Using RCTUIColorFromSharedColor everywhere Summary: Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23753508 fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5 * Fabric: Color conversion functions now do not depend on internal implementations of SharedColor Summary: This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand. This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23753510 fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013 * Fabric: Using `optional<int>` instead of `CGColorRef` on iOS Summary: Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`. Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because: * Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small. * Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`. On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value". This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values. If this solution works fine on iOS, I will do unify all implementations among all platforms. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23753507 fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db * Fabric: Using pre-cached UIColor objects for black, white, and clear colors Summary: This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.) Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23753506 fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246 * Coalesce touchMove events Summary: Changelog: [Internal] To align more closely with Paper, Fabric should coalesce touchMove events. on iOS it happens: https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/React/Base/RCTTouchEvent.m?lines=43 Reviewed By: JoshuaGross Differential Revision: D23734212 fbshipit-source-id: a9d324a6481884905d7be6637fcafe4e71f2bd9f * Fix LayoutAnimations assertion on `adjustDelayedMutationIndicesForMutation` Summary: `adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23746617 fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e * Fix MountingCoordinator override mode Summary: In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later. I also ensure that the TransactionNumber is incremented in that case. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23746684 fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d * Fix MountingCoordinator RN_SHADOW_TREE_INTROSPECTION + LayoutAnimations Summary: Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree. Just check that the tree exists before trying to print it. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23747289 fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a * Fix compilation for LayoutAnimations debug mode Summary: iOS needs this function to be marked as static. Changelog: [internal] Reviewed By: shergin Differential Revision: D23749613 fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964 * LayoutAnimations: at the end of every animation, issue an update mutation Summary: LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree. This unblocks iOS debug mode crashes. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23753606 fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593 * Layout Events: throttle layout events sent to same node repeatedly Summary: Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount. The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum. This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize. Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not. Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23719494 fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8 * Copy all blocks generated by TurboModules Summary: The Apple documentation states: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1 > Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap. All blocks generated in the TurboModule infra, for callbacks and promise resolve/reject handlers, can be used after the destruction of the scope within which they were declared. Therefore, let's copy them in the hopes that they mitigate T75876134. **Note:** We copy blocks before pushing them into the `retainedObjects` array in the legacy Infra as well. Context: D2559997 (71da2917e5), D5589246 (2a6965df90) Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23764329 fbshipit-source-id: e71360977bdff74dc570bd40f0139792860f811f * Upgrade Hermes dependency to 0.7.0 Summary: Use the latest published release of hermes-engine. Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0 allow-large-files Reviewed By: cpojer Differential Revision: D23725129 fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b * Fabric: Enabling state auto-repeating for all state updates (gated) Summary: This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co. This change is gated with MC. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23762508 fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5 * Stop accessing JVM in ~JavaTurboModule Summary: Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program. I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3). Changelog: [Internal] Reviewed By: ejanzer Differential Revision: D23744777 fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d * Improve performance logger definition and type safety Summary: The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined. This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive. Changelog: [Internal][Changed] - Replaced object literals with class instances to create performance loggers Reviewed By: lunaleaps Differential Revision: D23758609 fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c * Remove unused timespan descriptions from performance loggers Summary: The `description` parameter is never used so we can simplify the API. Changelog: [Internal][Changed] Removed `description` option from performance logger timespans Reviewed By: lunaleaps Differential Revision: D23758829 fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569 * Remove unnecessary addTimeAnnotation method from performance logger Summary: Changelog: [Internal][Removed] Removed `addTimeAnnotation` method from performance loggers Reviewed By: lunaleaps Differential Revision: D23758816 fbshipit-source-id: 98e0abae25266f3dcc5953f25f20cde8e3dac190 * Remove update option from stopTimestamp method in performance loggers Summary: Changelog: [Internal][Changed] Removed `update` option from `stopTimestamp` method in performance loggers Reviewed By: lunaleaps Differential Revision: D23759138 fbshipit-source-id: bb83b6f5ff2f640733c2e508779b3bc52800e4f6 * Propagate nativeID in createAnimatedComponent Summary: Changelog: [internal] https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/Libraries/Animated/createAnimatedComponent.js?commit=1b6ce6c3a69a&lines=82-112 `_isFabric` in `createAnimatedComponent` returns false for Fabric component, that's why nativeID was not being assigned and view got flattened. To fix this, props.nativeID is propagated. SnackBar already has nativeID https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/RKJSModules/Libraries/FDS/FDSLightweightFeedback/DEPRECATED_FDSSnackBar.js?commit=1b6ce6c3a69a&lines=277 Reviewed By: PeteTheHeat Differential Revision: D23757304 fbshipit-source-id: 9e4b4599c95b8af8767793bc8cdce717a347a273 * Reintroduce experiment flag for Reparenting/Flattening Differ Summary: This flag was deleted in D23374948 (6729a3e0bf), reintroduce it. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23771273 fbshipit-source-id: ae9595194bf14bc740d05b2ca6e7b5e22bdd566f * Add cause to jsi::instrumentation::collectGarbage Summary: Continuing the adding of a "cause" field for logging to GCs. This allows embedders of Hermes (such as React Native) to specify the cause of a call to `collectGarbage`. Notably, this allows Hermes to know when a GC is triggered by a memory warning. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23742099 fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518 * Update Flipper (#29787) Summary: The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it. Fixes This fixes https://github.com/facebook/react-native/issues/29492 / https://github.com/facebook/flipper/issues/1399 ## 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][changed] - Update Flipper to 0.54 Pull Request resolved: https://github.com/facebook/react-native/pull/29787 Test Plan: Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present. Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error: ``` make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni' make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni' fcntl(): Bad file descriptor [armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp /Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt' make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni' return int(wrapNoInt(open, name, flags, mode)); ^~~~~~~~~ /Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F' ssize_t wrapNoInt(F f, Args... args) { ^ 1 error generated. make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1 make: *** Waiting for unfinished jobs.... fcntl(): Bad file descriptor make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni' [armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp ``` No idea if it is related. I guess not since without making the change I got the same error. Reviewed By: mweststrate Differential Revision: D23767388 Pulled By: fkgozali fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e * Fix flattening/unflattening case on Android Summary: There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily. See comments for further justification on why deleteView can do less work overall. In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23775453 fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe * Have BatchMountItem log the exact item that crashes Summary: Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item. This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23775500 fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6 * Additional differ test: flattening differ should not produce DELETE and CREATE mutation for the same tag in the same frame Summary: See additional assertion. Tests still pass, so no other change was necessary. Changelog: [Internal] Differential Revision: D23775553 fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0 * Fabric: Removing catching all exceptions in UIManager::completeRoot Summary: This is a revert of D23529233 (902611f148). It turns out it was a bad idea. With this catch-all thing, we don't get new information. Yeah, we crash earlier now but seems we have even less information about the crash. :( I think D23754284 (04c874bd9c) should fix the issue. Changelog: [Internal] Fabric-specific internal change. Original commit changeset: 7ac7fb26ac08 Reviewed By: sammy-SC Differential Revision: D23786086 fbshipit-source-id: 86784df0193abfb7328c4d5a16a9af4214e9a161 * Fabric: Marking all JS function lambdas `noexcept` in UIManagerBinding Summary: Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue). Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core. This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling. I hope that will give us much more informative crash reports. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D23787492 fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642 * Move TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule Summary: This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout. changelog: [internal] Internal Reviewed By: RSNara Differential Revision: D23362253 fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37 * Notify ViewManagers when a View is deleted Summary: In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted. Bring back that behaviour. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23801666 fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888 * Prevent calling onTextLayout with the same value Summary: Changelog: [internal] In D23648430 (a315e4cd30) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout` to be called. Therefore, changes from D23648430 (a315e4cd30) need to be reverted. To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS. Reviewed By: shergin Differential Revision: D23782717 fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179 * TurboModule Android: compile TurboModule C++ Core into ReactAndroid Summary: This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS. New shared libs: * libreact_nativemodule_core.so: The TurboModule Android core * libreact_nativemodule_manager.so: The TurboModule manager/delegate To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23805717 fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9 * Add additional logging and asserts to StubViewTree Summary: Helps in testing LayoutAnimations or differ changes. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23797890 fbshipit-source-id: 1e612c04f9fbb256f2ace8a4a2ed9a477b4695a1 * Deleting unnecessary Differentiator code Summary: In the new Flattening differ, I experimentally verified that these two code paths are not hit (or redundant) and deleted them. One of the branches did nothing and the other produced duplicate DELETE mutations for the same tag, that is handled elsewhere. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23806161 fbshipit-source-id: 9ad2929e2d719a7b9b34640ed35f7a696103604b * LayoutAnimations: simplify index adjustment, (un)flattening detection Summary: In this diff I simplify index adjustment and add comments to rigorously describe what we're doing at each step of index adjustment. I've also made unflattening detection more correct, robust, and slightly more efficient. Bugs that existed before: 1) The reparenting detection that existed in the animations layer had some subtle bugs. I don't have proof that it results in any correctness issues or crashes, but I suspect it. 2) Correctness of index adjustment: there were cases where the Android mounting layer would crash because LayoutAnimations would try to remove a View at an index, but the index was wrong. This is why I sat down and diagrammed the relationships between all the bits of data we have for index readjustment - I believe this to be correct now. 3) Correctness of INSERT index adjustment: I had the insight that when we have batches of INSERTs to consecutive indices, we essentially want them to be treated as a single INSERT for adjustment purposes, so that they're all placed consecutively in the view layer. I added `ConsecutiveAdjustmentMetadata` to deal with this, and there are more comments in the code. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D23806163 fbshipit-source-id: cd9e94945034db8b840f2a806c6377034a91af61 * Deploy Flow v0.134.0 Summary: Changelog: [Internal] Reviewed By: dsainati1 Differential Revision: D23769795 fbshipit-source-id: 520e3974a53ba5961a081219c0cbf19b7dfade06 * Daily `arc lint --take CLANGFORMAT` Reviewed By: zertosh Differential Revision: D23811656 fbshipit-source-id: 4104948d2e4db786998320bcfdb1598d4a497f2d * Add extras to timespan and points in performance logger Summary: Changelog: [Internal][Added] Added point-level extras to performance logger Reviewed By: lunaleaps, rubennorte Differential Revision: D23730275 fbshipit-source-id: 285c5d7ac769bd109df7ce0294da024401edf7d3 * Making Android versionCodeOverride for new apps using the template human-readable (#29808) Summary: The current calculation on versionCodeOverride is not human-readable. Imagine if we have an android app with **versionName** `4.0` and **version code** `4`. In the current implementation, the result of **versionCode** `4` for `armeabi-v7a` will be the seemingly arbitrary **1048580**. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (`abiVersionCode * 1000 + variant.versionCode`). 39d7a019c1/packages/flutter_tools/gradle/flutter.gradle (L643-L647) With this change, our app with `versionCode 4 versionName "4.0"` for `armeabi-v7a` will have **1004** as the version code instead of the seemingly arbitrary **1048580**. As you can see adopting the flutter style implementation make the version code easier to read and debug. **1004** **1** - The ABI Type `["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]` **004** - Our versionCode. Hopefully, this can prevent future issues like this https://github.com/facebook/react-native/issues/29790. ## Changelog [Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable Pull Request resolved: https://github.com/facebook/react-native/pull/29808 Reviewed By: sammy-SC Differential Revision: D23804632 Pulled By: fkgozali fbshipit-source-id: 89b2c196b3bfe01fa608dfb595db6d3314ca1d63 * Codegen Android: adjust JNI output to compile from Gradle Summary: This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle: * Use `#include` instead of `#import` for header files * Added `#pragma once` * Removed direct include of `<fb/fbjni.h>` -- this is not necessary * Added generated Android.mk file based on library name Changelog: [Internal] Reviewed By: shergin Differential Revision: D23809082 fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d * Codegen Android: Compile ReactAndroid codegen C++ output Summary: Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var. Note: RNTester specific C++ spec files are not compiled here. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23809081 fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44 * Use Element<> in FindNodeAtPointTest Summary: Changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D23815171 fbshipit-source-id: bf420be172a55a966f8881371473e121c3848c78 * Fix ordering of children in LayoutableShadowNode::findNodeAtPoint Summary: Changelog: [internal] `LayoutableShadowNode::findNodeAtPoint` was iterating children in incorrect order and wasn't taking zIndex into accout. Reviewed By: JoshuaGross Differential Revision: D23814866 fbshipit-source-id: 38eee297147a5c5912304d139bb10f8b16ae2ee1 * Call stopObserving on correct queue Summary: Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue. Changelog: [iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue Reviewed By: RSNara Differential Revision: D23821741 fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f * Pull out construction of Layout from TextLayoutManager.measureText into separate function Summary: Changelog: [Internal] Construction of Layout will be needed in `TextLayoutManager.measureLines`, pulling it out into separate function prevents code duplication. Reviewed By: shergin Differential Revision: D23782905 fbshipit-source-id: 8ab817559ca154716a190ca1012e809c5fa2fd6e * Wire call from C++ to Java to get lines measurements Summary: Changelog: [Internal] Reviewed By: shergin Differential Revision: D23782998 fbshipit-source-id: fa9bda274c024d5bbd3ca24f394b5d76f8c07ad2 * Implement onTextLayout on Text component. Summary: Changelog: [Internal] Add `Text.onTextLayout` implementation to Android's Text component. Reviewed By: JoshuaGross Differential Revision: D23782311 fbshipit-source-id: fdb5709aaf68efee0ab895a6661396f92cfc768a * Fix Xcode bundler in staging and release (#29477) Summary: Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (https://github.com/facebook/react-native/issues/28354)" This reverts commit a8e85026cf. This commit a8e85026cf somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here https://github.com/facebook/react-native/issues/29205 ## Changelog [iOS] [Fixed] - fix "main.jsbundle does not exist" issue Pull Request resolved: https://github.com/facebook/react-native/pull/29477 Test Plan: With react-native-xcode.sh from RN v0.63.2  With my changes  Reviewed By: sammy-SC Differential Revision: D23817847 Pulled By: hramos fbshipit-source-id: 4b729c1231d30e89073b2520aeadee944c84421c * New Share API Use Cases (#29856) Summary: * New use cases for share API in rn-tester ## Changelog [General] [Changed] - Changed use cases for share API in rn-tester ## Test Plan * Tested app in both Android and iOS   Pull Request resolved: https://github.com/facebook/react-native/pull/29856 Reviewed By: hramos Differential Revision: D23784222 Pulled By: rickhanlonii fbshipit-source-id: f311201a49e0a76abb6634232106ed756143da30 * Open source react-native-modules ESLint rule Summary: Open source this ESLint rule so that we can lint our open source NativeModule specs. Changelog: [Internal] Reviewed By: shergin, cpojer Differential Revision: D23791748 fbshipit-source-id: e44444bc87eaa9dc9b7f2b3ed03151798a35e8a5 * feat: enable bitcode (#365) Summary: Bitcode is turned on by default in React Native and so, setting it here as well. Changelog: [iOS] [Changed] - Upgraded JSI with a new HERMES_ENABLE_BITCODE flag Pull Request resolved: https://github.com/facebook/hermes/pull/365 Reviewed By: tmikov Differential Revision: D23823228 Pulled By: Huxpro fbshipit-source-id: d43638818a733f6a87b2f4a1ecadad8ea9c7a419 * Add new ReactMarkers for bridgeless init start/end Summary: Adding two new ReactMarkers for start and end of bridgeless initialization. Creating new ones instead of reusing existing ones to make it easier to differentiate data from the bridge vs. bridgeless, and also because our existing markers 1) aren't very easy to understand, and 2) don't map cleanly to the new architecture. Reviewed By: PeteTheHeat Differential Revision: D23789156 fbshipit-source-id: 2ed10769e08604e591503a2bc9566aeb1d0563ed * Set useLineSpacingFromFallbacks when measuring text Summary: Changelog: [internal] When paper measures text, it sets `useLineSpacingFromFallbacks` flag on the Layout object. In Fabric this was missing and can cause incorrect layout. Reviewed By: JoshuaGross Differential Revision: D23845441 fbshipit-source-id: 538f440cdbbf8df2cba0458837b80db103888113 * Make React-Core compatible with Swift modules (#29995) Summary: Related to https://github.com/facebook/react-native/issues/29633 Support Swift based libraries using Xcode 12’s build system. ## Changelog [iOS] [Fixed] - Support Swift based libraries using Xcode 12’s build system. Pull Request resolved: https://github.com/facebook/react-native/pull/29995 Test Plan: * Building RNTester still works * Swift based pod tested in https://github.com/mrousavy/react-native-blurhash/issues/58 Reviewed By: fkgozali Differential Revision: D23824438 Pulled By: appden fbshipit-source-id: 418caf9808cb6326e3d6efdc8b37131a5705e7f6 * Sort logger alphabetically Summary: Rearranging to alphabetically sort, no functionality changes Changelog: [Internal] Reviewed By: rubennorte, motiz88 Differential Revision: D23836997 fbshipit-source-id: 00232b88379e44920ecb74fa6ff43f36d941d93b * Add close() to IPerformanceLogger Summary: To represent a final state where a logger should no longer be used Changelog: [Internal] - To represent a final state where a logger should no longer be used Reviewed By: rubennorte Differential Revision: D23845307 fbshipit-source-id: 4b2bfda4f7425ba6bc8e5e1233d9baea60dd8667 * RNTester Android: Add stub C++ for TurboModule provider (#30014) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/30014 This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle. Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html Note that `ANDROID_NDK` env var is honored to pick the right NDK version. For now, this is gated behind `USE_CODEGEN` env variable. Changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D23887058 fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c * New Button Component Use Cases (#29848) Summary: * New use cases for button component in rn-tester * E2E tests for the button component ## Changelog [General] [Changed] - Changed use cases for button component in rn-tester ## Test Plan  After -  Before -  Pull Request resolved: https://github.com/facebook/react-native/pull/29848 Reviewed By: hramos Differential Revision: D23649694 Pulled By: rickhanlonii fbshipit-source-id: 3590eca08ea58c771596ad731f74eb233b1a40d8 * Minor Code Improvements in RNTester (#29868) Summary: * Update single-letter variable names to be more descriptive * Remove event listener on component unmount * Add flow types * Refactor RNTesterNavbar to use descriptive component names Pull Request resolved: https://github.com/facebook/react-native/pull/29868 Reviewed By: hramos Differential Revision: D23598579 Pulled By: rickhanlonii fbshipit-source-id: c5cfc61d7b2fcb2942bf149d0a8ba0b58b0192e6 * Prevent change of delegate in RCTUITextView Summary: Changelog: [internal] # Problem `[RCTUITextView setDelegate]` is a public method and if something changes the delegate, appropriate events won't be called on the component (onTextChange, onSelectionChange and the others). # Solution Prevent setting of delegate from outside of the class. Ideally we would want to hide `setDelegate` altogether but that would require a rewrite of `RCTUITextView`. Reviewed By: JoshuaGross, shergin Differential Revision: D23813095 fbshipit-source-id: 8b76ac86727d262d0f9b81adfc8e75157847284c * Fix touch handling in bridged paper components Summary: Changelog: [internal] If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter. To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter. Reviewed By: shergin Differential Revision: D23840054 fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3 * TurboModule Android: add dependency on ReactAndroid codegen output to RNTester Summary: This adds shared libraries dependencies to RNTester so that it can call `ReactAndroidSpec_ReactAndroidSpec_ModuleProvider()` C++ lookup function. That function is generated by the react-native-codegen during build time. This does not make RNTester use TurboModule yet, just the necessary setup to link the C++ libs together. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23901952 fbshipit-source-id: fd5ee0ca266609207962adc5ceaf814956052eec * Fix rounding in Slider component Summary: Changelog: [Internal] There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper. Reviewed By: JoshuaGross Differential Revision: D23903493 fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc * Do not override decoders to RCTImageLoader (#29711) Summary: I (actually, [we](https://github.com/expo/expo/issues/9858)) noticed GIFs are no longer animating in Expo client after [enabling TurboModules](https://github.com/expo/expo/pull/9687). ## Changelog [iOS] [Fixed] - Fix `RCTImageLoader` not using decoders provided. <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> Pull Request resolved: https://github.com/facebook/react-native/pull/29711 Test Plan:  The cat is moving! Before applying this commit `RCTGIFDecoder` provided in the initalizer is removed from the `_decoders` array in the ```objc _decoders = [_bridge modulesConformingToProtocol:protocol(RCTImageDataDecoder)]; ``` Also, compare 8f306cd66a/Libraries/Image/RCTImageLoader.mm (L243-L250) and 8f306cd66a/Libraries/Image/RCTImageLoader.mm (L177-L184) This PR makes `_decoders` behave the same as `_loaders`. Reviewed By: PeteTheHeat Differential Revision: D23908238 Pulled By: fkgozali fbshipit-source-id: 1d7a6e0d180277f23d8c28916734713bc1833b8b * Fix rounding issue when setting padding Summary: Changelog: [Internal] Padding needs to be rounded down (floor function), not rounded to the closest natural number. Otherwise the content of the view might not fit. Reviewed By: JoshuaGross Differential Revision: D23905145 fbshipit-source-id: e84d70155b207144b98646dd0c4fea7a8c4bd876 * LayoutAnimations: force props to update when executing "final" mutations Summary: When an animation is completed or a conflicting animation is detected, force props, state, layout, etc to update. Currently, when a final animation mutation is queued, some attributes can be updated but not others, causing unexpected visual glitches at least on Android. Some of these are arguably component bugs, but it's easier to just flush all attributes by tricking the platforms into updating all attributes. This will also prevent us from having to track down more of these bugs, potentially. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23886519 fbshipit-source-id: 8e5081bbe3b7843c16c0f283fa07fdec0e211aa8 * TurboModule Android: compile codegen C++ output into librntester_appmodules.so Summary: The react-native-codegen provides Android.mk in the Android C++ output, but for RNTester (or hosting apps), we should just compile the codegen output with the rest of the app-specific C++ files. This is to simplify the build configuration, and also to not add too many additional .so libs to the APK. With this commit, `RNTesterAppModuleProvider.cpp` should be "complete" for RNTester use-case. This TurboModule lookup function is the one described in https://github.com/react-native-community/discussions-and-proposals/issues/273. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23913149 fbshipit-source-id: d1ca136787b87a0e8e6504318e1f0a78efef46ea * Follow-up for fixing xiaomi NullPointer crash Summary: This is a follow-up for fixing the xiaomi NullPointer crash (D23331828 (07a597ad18) D23451929 (b5b4a70410)): 1, Clean up previous temporary fix in js. 2, Cover all cases including caretHidden is set and isn't set, in previous fix if caretHidden isn't set then fix won't be executed. Changelog: [Internal] Reviewed By: makovkastar Differential Revision: D23816541 fbshipit-source-id: a7543f6767430abb74141a747b08391986662958 * Workaround for Date Picker in iOS14 Summary: iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style. This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well. This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23935328 fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc * Group accessible views using the view hierarchy Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO. Reviewed By: sammy-SC Differential Revision: D23844265 fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810 * Fabric: Fixed crash in `colorComponentsFromColor()` Summary: This fixes a recently introduced crash in `colorComponentsFromColor()` (iOS implementation) caused by dereferencing a null pointer. The fix is just a copy of a code fragment from a previous implementation. Reviewed By: fkgozali Differential Revision: D23944812 fbshipit-source-id: 977135dd75c4375affddfd75183e4890618ae819 * round up layoutWidth for Android 11 in ReactTextShadowNode Summary: in Android 11, there's an issue where Text content is being clipped. The root cause appears to be a breaking change in how Android 11 is measuring text. rounding up the layoutWidth calculation mitigates the issue. Changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D23944772 fbshipit-source-id: 1639259da1c2c507c6bfc80fed377577316febac * Don't crash when promise task is cancelled before its resolved (#29969) Summary: This pull request fixes a potential `TypeError` in TaskQueue.js, that happens if a promise is added to the task queue, which is cancelled between the promise starting and resolving. The exact error this resolves is ```js TypeError: TaskQueue: Error resolving Promise in task gen1: Cannot set property ‘popable’ of undefined 167 | queueStackSize: this._queueStack.length, 168 | }); > 169 | this._queueStack[stackIdx].popable = true; | ^ 170 | this.hasTasksToProcess() && this._onMoreTasks(); 171 | }) 172 | .catch(ex => { at Libraries/Interaction/TaskQueue.js:169:46 ``` This specific error was also reported in https://github.com/facebook/react-native/issues/16321 ## Changelog [General] [Fixed] - Prevent TypeError in TaskQueue when cancelling a started but not resolved promise. Pull Request resolved: https://github.com/facebook/react-native/pull/29969 Test Plan: The added test demonstrates the error, if run without the fixed applied to TaskQueue.js. This is a race condition error, so is difficult to replicate! Reviewed By: yungsters Differential Revision: D23785972 Pulled By: appden fbshipit-source-id: ddb8d06b37d296ee934ff39815cf5c9026d73871 * Android: consolidate various prebuilt C++ .so configuration into Android-prebuilt.mk Summary: To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D23938538 fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87 * TurboModule Android: rename libreact_nativemodule_manager to libturbomodulejsijni Summary: TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D23946945 fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61 * TurboModule Android: Implement TurboModuleManagerDelegate specific to RNTester Summary: This provides the RNTester specific impl of the manager delegate. The class is responsible to provide module lookup during runtime for TurboModule, and the C++ impl is using the codegen-generated lookup functions from :ReactAndroid and :packages:rn-tester:android:app Gradle targets. Note: RNTester still needs to explicitly enable TurboModule and instantiate this manager before it can activate TurboModule. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D23938537 fbshipit-source-id: 7957847ecc58fef8d9a276d9d3d477ecec36a700 * TurboModule Android: allow RNTester to activate TurboModule system Summary: If built with `USE_CODEGEN=1` flag set, RNTester now activates the TurboModule system, also using various codegen output from the previous commits. Note that this is very early integration, and not thoroughly tested yet. To verify: ``` console.warn('TM enabled?', global.__turboModuleProxy != null); ``` {F337454276} Changelog: [Internal] Reviewed By: yungsters Differential Revision: D23946944 fbshipit-source-id: 5838aeb9ded07b1cc0fcb069535d1c6fb3725973 * Fix passing react native path in Podfile template (#29285) Summary: Since e949e234b0 (diff-d1800049b92343288bcbc1c484575058) the RN cli script returns an object with `:reactNativePath` instead of just JSON. Not super familiar with how objects / JSON works in ruby but using this syntax instead works. ## Changelog [Fixed] [iOS] - Fix passing react native path in Podfile template Pull Request resolved: https://github.com/facebook/react-native/pull/29285 Test Plan: Tested in a project inside a monorepo using the latest version of RN CLI that the proper react-native path is now passed. Reviewed By: fkgozali Differential Revision: D23941162 Pulled By: hramos fbshipit-source-id: 0115412ec6d6bca101612d760dfc00cf89d97f1e * Animated: Early detection of division by zero in AnimatedDivision Summary: Same as D20969087 (be78673755) but a bit more sophisticated. We currently see a lot of errors happens because of division by zero in AnimatedDivision module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens. Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable. Changelog: [Internal] Fabric-specific internal change. Reviewed By: fkgozali Differential Revision: D23908993 fbshipit-source-id: d21be9a72ec04fe4ff0740777d9ff49cf1bcde73 * Fabric: Failing early in case if a argument of `-[RCTComponentViewFactory registerComponentViewClass:]` is nil Summary: Subject. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D23914517 fbshipit-source-id: 1c909e7d21b12326881990ecf855e814bf957f3c * Fabric: Adding `#pragma once` to `ImageTelemetry.h` Summary: Without this thing some stuff does not compile. Changelog: [Internal] Fabric-specific internal change. Reviewed By: fkgozali Differential Revision: D23948622 fbshipit-source-id: f066ada183c0fd6a7b5eec542395d44bbbfe80a3 * Make blocking people work in Dating Settings Summary: Blocking people didn't work in Dating Settings without the Bridge. Changelog: [Internal] Reviewed By: ejanzer Differential Revision: D23904867 fbshipit-source-id: 4a68b9d99fcc812f6616783a06dc047a3bc64491 * Fix slider's initial value Summary: Changelog: [Internal] value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum. Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value). See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more. Reviewed By: JoshuaGross Differential Revision: D23903545 fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd * Do not attach root view until size is available Summary: Changelog: [internal] # Why is text laid out twice in Fabric? Layout constraints (min and max size) change during startup of Fabric surface. 1. `Scheduler::startSurface` is called with max size being {inf, inf}. 2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport. These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size. # Fix Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}. Reviewed By: JoshuaGross, yungsters Differential Revision: D23866735 fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d * RNTester: Add TextInput example to RTL tester Summary: Add a TextInput to RTL screen in RNTester, to test RTL languages with TextInput. Changelog: [Internal] Reviewed By: shergin Differential Revision: D23914627 fbshipit-source-id: 84c62efe7034c0dfa2ef21be3f085880292c3930 * Update PerformanceLogger to nullable timespans, points, extras Summary: Changelog: [Internal][Fixed] - When we close performance loggers (D23845307 (aebb97b9c6)) we cannot rely that a timespan/point/extra will be in perf logger. Update types to reflect that. Reviewed By: rubennorte Differential Revision: D23907741 fbshipit-source-id: 63673aa69cd8c76253e4fee3463e37c86265cf7b * Make the Instagram app compile again Summary: Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23948336 fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627 * Pressability: Support Lazy Hook Initialization Summary: Changes `usePressability` so that it accepts a nullable `config` argument. This makes it possible for a component to use `usePressability` and lazily allocate the `config` and subsequent instance of `Pressability`. This can be useful for components that are commonly allocated but seldom pressed because it lets many usages of `usePressability` avoid allocating many extraneous objects. Changelog: [Internal] Reviewed By: kacieb Differential Revision: D23708206 fbshipit-source-id: 4a5063067131ce8c957fb16c49a2045e8c0b19fa * Text: Cleanup Native Component Configuration Summary: Cleans up the native component configuration for `RCTText` and `RCTVirtualText`. This //does// lead to a breaking change because `Text.viewConfig` will no longer exist. However, I think this is acceptable because `viewConfig` has already long stopped being an exported prop on other core components (e.g. `View`). Changelog: [General][Removed] - `Text.viewConfig` is no longer exported. Reviewed By: shergin Differential Revision: D23708205 fbshipit-source-id: 1ad0b0772735834d9162a65d9434a9bbbd142416 * remove most of tvOS remnants from the code (#29407) Summary: Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018 This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code. In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now. ## 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 --> * **[Internal] [Removed]** - remove most of tvOS remnants from the code: * `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter` * **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages * **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method * **[iOS] [Removed]** - remove deprecated and TV related props from View: * `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties` * **[iOS] [Removed]** - remove `BackHandler` utility implementation Pull Request resolved: https://github.com/facebook/react-native/pull/29407 Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required. Reviewed By: PeteTheHeat Differential Revision: D22619441 Pulled By: shergin fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6 * chore: deduplicate lock, update packages repository fields (#30044) Summary: This small PR includes the following changes: * deduplicate yarn lock file using [`yarn-deduplicate`](https://github.com/atlassian/yarn-deduplicate) package * deduplicate script has been added as `update-lock`, let me know if you would like also to see this in [`postinstall`](https://docs.npmjs.com/misc/scripts) (to automatically optimize lock on every dependency change) * according to the [npm docs](https://docs.npmjs.com/files/package.json#repository): * main `package.json` repository field has been replaced with shorthand * monorepo packages repository field has been extended by `directory` The main goal of introducing deduplication script was to optimize the dependencies footprint while developing and speed up the initial installation process. Running `yarn-deduplicate` also increase the security in some way, because it enforces usage only of the latest version of the package. You can read more about the benefits in the deduplicate script [repository](https://github.com/atlassian/yarn-deduplicate#duplicated-packages). ## 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 --> [Internal] [Added] - add yarn lock deduplication script Pull Request resolved: https://github.com/facebook/react-native/pull/30044 Test Plan: `yarn install` was successful, this also should not affect yarn workspaces in any way. Reviewed By: GijsWeterings Differential Revision: D23959812 Pulled By: cpojer fbshipit-source-id: e2455e3718378e1ce6206e79463d4083f8fe5d47 * Daily `arc lint --take CLANGFORMAT` Reviewed By: zertosh Differential Revision: D23986055 fbshipit-source-id: 7bfe9f06f236f8866e812db060edf3d089fe253c * Convert AndroidDialogPicker to JS view configs Summary: Convert AndroidDialogPicker to JS view configs Changelog: [Internal] Reviewed By: ejanzer Differential Revision: D23911673 fbshipit-source-id: d5fefa997432f0096308ab5593ba74c2c07b71e1 * Fix dismissal animation of Modal Component Summary: Changelog: [Internal] Fabric removes components bottom up (from leafs to the root). This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation. To fix this, we snapshot contents of the Modal before any of its contents are removed. Reviewed By: shergin Differential Revision: D23976244 fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1 * Allow Java classes to hook into ScrollView scroll and layout events Summary: For advanced interop cases. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D23984345 fbshipit-source-id: f5c2a43a1bf5937f9974bcc5c66c36ec35e679c5 * Remove unused Fabric image instrumentation Summary: Remove the older implementation of image instrumentation in Fabric by removing, RCTImageInstrumentationProxy, ImageInstrumentation from ImageRequest, and trackURLImageContentDidSetForRequest from RCTImageLoaderWithAttributionProtocol. Changelog: [RN][Fabric][Image] Remove unused Fabric image instrumentation Reviewed By: fkgozali Differential Revision: D23990606 fbshipit-source-id: 004d04025d031af11377a73e5bfb64b1e0449962 * Split NativeImageStore into iOS and Android counterparts Summary: Split the two specs, so that that we don't have to use Flow unions in the merged spec. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23800841 fbshipit-source-id: 28b67578832ebd733bd080877e4ab763c013fded * Allow NativeModule method return types to use type aliases Summary: We already support type-aliases in our NativeModule method params. This diff extends the support to NativeModule method returns. **Note:** I need to see if I need to update the generators to handle this case. Will do that in this diff, after working through other higher priority stuff. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D22828839 fbshipit-source-id: cf5c756d3cacf067df217cdb6212946320a2d4be * Delete NativeModuleSchemaBuilderConfig type Summary: Unecessary, since `NativeModuleShape` is the exact same thing. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D23119784 fbshipit-source-id: 8c4aded88a97a80aa977c13cc27e32fbe68150aa * Restructure getTypes function Summary: There are two types of types we care about: - Type aliases - Interface Declarations These types can be exported. I think we should build the types dictionary from only those types. Everything else should be ignored. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23120241 fbshipit-source-id: 9f023081d0f9c85b45407b180ae7c3e7391eb725 * Clean up Module/Component detection logic in Flow parser Summary: Just broke down getConfigType into two separate functions: `isModule` and `isComponent`. - Cleaned up `isComponent`, to check for the the AST node types. - Re-implemented `isModule` - Improved error messages. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D23121896 fbshipit-source-id: 3df2b2e334c4cea8eabe2e73ecb9f1f1217e7be4 * Fix parser's buildSchema's return type Summary: `buildSchema` delegates to two other functions: `buildComponentSchema`, or `buildComponentSchema`. Both return have a return type of *required* `SchemaType`. Therefore, `buildSchema` can have a return type of `SchemaType`. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D23135499 fbshipit-source-id: f13db17549c93b965f372d9b68d06efc2a40c6cc * Clean up parsers/flow/modules/index.js Summary: Changes: - Adding type annotations, where possible - Delete unnecessary functions Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D23138227 fbshipit-source-id: b4b47492ddef49f496ed9fcb61ef1c000e3e8f18 * Colocate alias/method generation logic Summary: ## Changes - Generating the aliases was split over `parsers/flow/modules/index.js`, and `parsers/flow/modules/aliases.js`. I moved everything to the latter file. - Generating methods was split over `parsers/flow/modules/index.js` and `parsers/flow/modules/methods.js`. I moved everything to the latter file. - More type-safety Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23143382 fbshipit-source-id: e11b76bee7917a7db37ae7f1af64da5f046c5d1e * Cleanup buildMethodSchema and introduce nullable methods Summary: ## Changes - Started doing cleanup under `/parsers/flow/modules/methods.js` - Rename `NativeModuleMethodTypeShape` -> `NativeModulePropertyShape` - Moved optional property from `FunctionTypeAnnotation` to the `NativeModulePropertyShape` - Introduced a nullable property inside what was once `FunctionTypeAnnotation`. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23146050 fbshipit-source-id: 2fe97bb9c0736242682133e4923131a54bbea54b * Rewrite Flow module parser Summary: This diff: 1. Simplifies the NativeModule schema Flow types. 2. Simplifies the NativeModule Flow parser, to accomodate the modified schema, and to reduce code duplication. **Notes:** - If the parser detects an unrecognized type within the context of parsing an Array's element type, it'll omit the `elementType` property of the `ArrayTypeAnnotation`. Details: T72031674. **Rationale:** Basically, when an array element type is supported, we use it in our generators. When it's unsupported, we ignore it. In the unsupported case, there's no point in trying to parse the Array element type, which is why I decided to omit the `elementType` property. Ideally, our NativeModule specs would never use unsupported types, in any context. This would allow us to always parse and use the elementType. However, that seems like a it could be a hefty migration: we have > 400 specs. Since, this isn't a battle we need to fight right now, I left a TODO at the relevant lines instead. - The legacy codegen would generate structs for each object literal type in the file. In this re-implementation of the parser, I only insert into the aliases array when we detect a usage of a type-alias to an ObjectLiteral type annotation. With this decision, we won't be able to generate these unnecessary structs. This is good because we get rid of dead code. It's bad because it might make our migration to this codegen bit more difficult. [WARNING] This diff produces flow failures that will be addressed in subsequent diffs. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23201387 fbshipit-source-id: 55ce0df925a8bae0e7d5bb2a9b63167607eba461 * Add unit tests to validate module parser Summary: ## Test Structure - Parameter Parsing - For type in [optional, nullable, optional and nullable, required]: - Can parse Primitives - Can parse Object - Can parse Arrays - Can parse primitive element types - Can parse Object element types - Can parse Array element types - Can parse Reserved Type element types - Can parse Type alias element types - Can parse Object Literals - Can parse Function - Can parse Reserved Types (e.g: RootTag) - Can parse Type alias - Can parse Object Literals - For prop type in [optional, nullable, optional and nullable, required]: - Can parse primitive prop types - Can parse Object prop types - Can parse Array prop types - Can parse Reserved Type prop types - Can parse Type alias prop types - Can parse Object Literal prop types - Return Parsing - For type in [nullable, required]: - Can parse Promises - Can parse Primitives - Can parse Object - Can parse Arrays - Can parse primitive element types - Can parse Object element types - Can parse Array element types - Can parse Reserved Type element types - Can parse Type alias element types - Can parse Object Literals - Can parse Function - Can parse Reserved Types (e.g: RootTag) - Can parse Type aliases - Can parse Object Literals - For prop type in [optional, nullable, optional and nullable, required]: - Can parse primitive prop types - Can parse Object prop types - Can parse Array prop types - Can parse Reserved Type prop types - Can parse Type alias prop types - Can parse Object Literal prop types Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23089925 fbshipit-source-id: 73c3b1ef33b402265c14f0ac9e364414a5d54dca * Fix type alias nullability resolution in module parser Summary: Consider this case: ``` type Animal = ?{| name: string, |}; type B = Animal export interface Spec extends TurboModule { +greet: (animal: B) => void; } ``` The generated output for this spec is: ``` namespace JS { namespace NativeSampleTurboModule { struct Animal { NSString *name() const; Animal(NSDictionary *const v) : _v(v) {} private: NSDictionary *_v; }; } } protocol NativeSampleTurboModuleSpec <RCTBridgeModule, RCTTurboModule> - (void)greet:(JS::NativeSampleTurboModule::Animal &)animal; end ``` Observations: 1. The codegen looks as though we wrote `+greet: (animal: ?Animal) => void;` as opposed to `+greet: (animal: B) => void;` 2. The generated struct is called `Animal`, not `B`. ## After this diff Whenever we detect a usage of a type alias, we recursively resolve it, keeping a track of whether the resolution will be nullable. In this example, we follow B to Animal, and then Animal to ?{|name: string|}. Then, we: 1. Replace the `B` in `+greet: (animal: B) => void;` with `?Animal`, 2. Pretend that `Animal = {|name: string|}`. Why do we make all type alias RHSs required? 2. This design is simpler than managing nullability in both the type alias usage, and the type alias RHS. 3. What does it mean for a C++ struct, which is what this type alias RHS will generate, to be nullable? ¯\_(ツ)_/¯. Nullability is a concept that only makes sense when talking about instances (i.e: usages) of the C++ structs. Hence, it's better to manage nullability within the actual TypeAliasTypeAnnotation nodes, and not the associated ObjectTypeAnnotations. ## Other Changes - Whenever we use the `Animal` type-alias, the e2e jest tests validate that the type alias exists in the module schema. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23225934 fbshipit-source-id: 8316dea2ec6e2d50cad90e178963c6264044f7b7 * Export module type annotations from CodegenSchema Summary: This diff has a few changes: - All type annotations are now declared top-level, and exported from `CodegenSchema.js`. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23616473 fbshipit-source-id: 1509c304305e56674bd76c44bc49f755dfeaa332 * Refactor: Introduce Required<T> generic type Summary: This diff introduces a `Required<T>` generic type in CodegenSchema. Why? NativeModule aliase RHSs are basically ObjectTypeAnnotations but they have `nullable` fixed to `false`. This generic type reduces duplication in the schema flow types. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23645208 fbshipit-source-id: da984f64fa17d8533a3ea74b132ce10aae9aa7ed * Refactor: Make NativeModuleAliasMap $ReadOnly Summary: We were using `$ReadOnly<NativeModuleAliasMap>` everywhere, so I figured we'd just make the type itself `$ReadOnly`. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23645207 fbshipit-source-id: 4e018d5768f4fcfd00492def7d840a5054cb2b73 * Rename GenericPromiseTypeAnnotation to PromiseTypeAnnotation Summary: We have first class support for Promises in our codegen. So, it's more appropriate to just call this PromiseTypeAnnotation, as opposed to GenericPromiseTypeAnnotation. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23645209 fbshipit-source-id: bfc0b909750e221e18be33acf197f342a2918aa9 * Refactor: Make NativeModuleArrayTypeAnnotation elementType customizable Summary: In the future, we'll use `NativeModuleArrayTypeAnnotation` inside JS struct objects. Structs cannot contain `ObjectTypeAnnotations` anywhere. Therefore, we need the elementType of `NativeModuuleArrayTypeAnnotation`'s elementType customizable. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23645210 fbshipit-source-id: 97abb993d59536ebd68ec08b18ce7f2801c68a2d * Update generator fixtures to comply with Schema flow types Summary: In diffs below, we made several changes to the NativeModule schema. This diff just ensures that the input to our generator snapshot tests, which are module schemas, are valid. Changelog: [Internal] Reviewed By: TheSavior Differential Revision: D23633942 fbshipit-source-id: 444ccd60f6ec76e348a8e54b946260464ff3aeee * Create utilities for module generators Summary: There are two operations we do in every NativeModule generator: - We convert the `SchemaType` into a map of NativeModule schemas - If the type-annotation is a TypeAliasTypeAnnotation, we resolve it by doing a lookup on the NativeModuleAliasMap. This is usually followed by an invariant to assert that the lookup didn't fail. Both procedures have been translated into utilities for use across our generators. I also deleted `getTypeAliasTypeAnnotation` which will no longer be used. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23667249 fbshipit-source-id: 4e34078980e2caa4daed77c38b1168bfc161c31c * Rewrite ObjC++ module generator Summary: ## Misc. Improvements * We now have 95%+ flow coverage in all generator files. Henceforth, we can make changes to these files with more confidence, and trust flow to catch more errors. This should also improve the DevX of working on these files. * Better templates: Instead of doing string replace with RegExps, we instead use functions and leverage JS template literals to generate our code. A few benefits: (1) data dependencies of templates are clearly visible, and statically checked by flow, (2) the templates are more readable in VSCode. * Merged the GenerateModuleHObjCpp.js and GenerateModuleMm.js generators. They can share a lot of logic, so it's not a good idea to keep them separate. * The ObjC++ module generator no longer generates “dead” structs (i.e structs that aren’t used by type-safety infra). In fact, it explicitly only supports the types in our Wiki. (I know this wasn’t the case with the legacy codegen, because we were generating native code for enums in the legacy codegen). This is a mixed bag. The test to verify correctness will be more difficult to write. However, keeping structs in the codegen needlessly complicates the parsers + generators, and creates technical debt for us to clean up later. ## Abstractions - **StructCollector:** As we serialize NativeModule methods, when we detect an ObjectTypeAnnotation in the return type of `getConstants()` or inside a method param, we must create a Struct JS object for it. When we detect a type-alias (also in the same locations), we must look up that type-alias and create a Struct from its RHS. A Struct is basically an ObjectTypeAnnotation with a context (i.e: used in getConstants() vs as a method param), that cannot contain other ObjectTypeAnnotations. - **serializeMethod.js** Given a NativeModule method type annotation, output the protocol method, JS return type, selector, a record of which params were structs, and which structs. Basically, this is all the information necessary to generate the declaration and implementation codegen for a partiular NativeModule method. - **serializeStruct/*.js**: After creating all these Structs, we need to loop over all of them, and tranform them into ObjC++ code. - **serializeStruct.js**: Depending on the struct context, calls either `serializeRegularStruct.js` or `serializeConstantsStruct.js`. Both of these files have the same layout/abstractions. They look very similar. - **serializeModule.js:** Outputs RCTCxxConvert categories for transforming `NSDictionary *` into C++ structs. Outputs ObjCTurboModule subclass. ## Algorithm ``` for spec in NativeModuleSpecs structCollector = new StructCollector resolveAlias = (aliasName) => nullthrows(spec.aliases[aliasName]) methodDatas = [] for method in methods(spec) methodData.push(serializeMethod(method, structCollector, resolveAlias)) end structs = structCollector.getStructs() output generateImplCodegen(methodDatas, structs) output generateHeaderCodegen(methodDatas, structs) end ``` Changelog: [Internal] Reviewed By: hramos Differential Revision: D23633940 fbshipit-source-id: 7c29f458b65434f4865ef1993061b0f0dc7d04ce * E2E snapshot test ObjC++ generator Summary: NativeModule specs exist under `react-native-github/packages/react-native-codegen/src/__tests__/modules/fixtures`. `GenerateModuleObjCpp-test.js` runs the RN Codegen on those NativeModule specs, and saves the output inside a snapshot. For convenience, the folowing command runs the legacy codegen on the fixtures: ``` buck build fbsource//xplat/js/react-native-github/packages/react-native-codegen/src/__tests__/modules:RNCodegenModuleFixtures-flow-types-ios --show-output ``` Changelog: [Internal] Reviewed By: hramos Differential Revision: D23637708 fbshipit-source-id: 3319f319515eca42b4499682313fea6e0bdc2a06 * Fix GenerateModuleCpp Summary: Just updating this generator to understand the new RN Codegen Module parser flow types. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23667254 fbshipit-source-id: 558dd7ac5b4541edf40248b8ab8bb50d31fa8624 * Fix GenerateModuleH Summary: Just updated the generator to work with the new RN Codegen Flow Parser types. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23667252 fbshipit-source-id: 34404a478ddd67446d82b5f98e1051300064e95c * Fix GenerateModuleJavaSpec Summary: Just updated the generator to work with the new RN Codegen Flow Parser types. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23667255 fbshipit-source-id: 40b7747aad89f6d5bbb9f42d59a4df9633060c66 * Fix GenerateModuleJniH Summary: Just updated the generator to work with the new RN Codegen Flow Parser types. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D23667250 fbshipit-source-id: f36b5418101c40331964d1f9ede7c6bd7924383d * Fix GenerateModuleJniCpp Summary: Just updated the generator to work with the new RN Codegen Flow Parser types. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23667253 fbshipit-source-id: ef94e75287d37dfd7b80f61455a1bfa34bddeb28 * Fix ObjC++ module generator output Summary: * Removed extraneous closing brace. * Fixed static method signature, replacing double colon with an underscore (`static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI::${methodName}()` -> `static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI_${methodName}()`). * Wrap `getConstants` selector name with `selector()`. * Pass through `getConstants` and `constantsToExport` to allow de-duping of `getConstants` method in generator output. Note that the FBReactNativeSpec that is output by the generator still has some issues that need to be addressed before it can be used. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D23910505 fbshipit-source-id: 37d884885b8878f38d40637377c2a74a728c3a13 * Fix ObjC++ structs and method mapping Summary: Adjust generated ObjC++ code to resolve a few build time and run time errors: * Suppress CONSTANTS struct implementations * Use type alias name as struct name when serializing arguments that involve a type alias * Use actual number of arguments for a method when generating method map. With these changes in place, RNTester can be built and run using the code that is generated by the new codegen. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23926500 fbshipit-source-id: 88fcbb795fd71dc8155eb26348db943975e13e84 * Remove header_namespace from module codegen target Summary: Making this change because I see this error when compiling Internationalization ``` ➜ fbsource buck build //xplat/js/RKJSModules/Libraries/Internationalization:generated_objcpp_modules-InternationalizationApple buck-out/gen/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generate_module_mm-Internationalization/FBReactNativeInternationalizationSpec-generated.mm:15:9: fatal error: 'FBReactNativeInternationalizationSpec.h' file not found #import "FBReactNativeInternationalizationSpec.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Command failed with exit code 1. command: [/Applications/Xcode_11.6.0_fb.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++, @/Users/ramanpreet/fbsource/buck-out/bin/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generated_objcpp_modules-InternationalizationApple#compile-FBReactNativeInternationalizationSpec-generated.mm.o... ``` Since the header namespace is "FBReactNativeInternationalizationSpec", we can only import the header file via "FBReactNativeInternationalizationSpec/FBReactNativeInternationalizationSpec.h", according to this buck documentation: https://buck.build/rule/cxx_library.html#headers. Not entirely sure how this target compiled before. The legacy codegen buck target also set the header namespace to "": https://fburl.com/diffusion/3p85qhf9. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23978436 fbshipit-source-id: c9cd7c710edf94df6df10778f8603870f92275a7 * Align multi-line TextInput onSubmitEditing behavior (#29177) Summary: Aligns behavior to be consistent with Android and the [documentation](https://reactnative.dev/docs/textinput#bluronsubmit). `onSubmitEditing` should not be called when `blurOnSubmit=false`. ## Changelog [iOS] [Fixed] - Align multi-line TextInput onSubmitEditing behavior Pull Request resolved: https://github.com/facebook/react-native/pull/29177 Test Plan:  Reviewed By: shergin Differential Revision: D22488870 Pulled By: hramos fbshipit-source-id: 2dec3a55da6384389a8358896ef1fbfd806d0304 * Fix mutation sorting function Summary: The sorting function currently forms a partial ordering, not a total ordering. This can cause problems with certain sequences of immediate or conflicting mutations, leading to UI corruption or crashes. Changelog: [Internal] Reviewed By: shergin Differential Revision: D24002668 fbshipit-source-id: edc9b4c1e3104897cb0c5fd6da563ec43d800494 * TurboModule Android: properly set up RNTester ndkBuild and cleanup dependencies Summary: Before RNTester compilation starts, it needs to wait for :ReactAndroid NDK build to finish, so that it knows where to find the exported .so files. This tells the `preBuild` task to depends on `:ReactAndroid:prepareReactNdkLibs` task. The .so files are now copied over to the local project build dir, instead of depending on :ReactAndroid's build dir. For cleanup, the reverse ordering is needed: before `clean` removed our temp dir to store the copied .so files, make sure the ndkBuild cleanup tasks execute beforehand. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23982989 fbshipit-source-id: 955d7c9bccb5855b6b066fca89764df2ede89f63 * TurboModule Android: move SampleTurboModule impl and spec to OSS Summary: This is the Java/JNI impl of the NativeSampleTurboModule.js, just like on iOS. The files here are supposed to be generated by the react-native-codegen, but they are checked in to the repo for easier build integration with RNTester. Changelog: [Internal] Reviewed By: hramos Differential Revision: D23985746 fbshipit-source-id: 46340d778f3d964efe5b538d15ebe0f2cab04862 * TurboModule Android: install SampleTurboModule and the playground to RNTester Summary: This compiles SampleTurboModule into RNTester Android. It also adds the NativeModule playground to show case TurboModule system to RNTester examples, just like in iOS. {F337854369} Changelog: [Android][TurboModule] Added TurboModule example to RNTester when `USE_CODEGEN` is set Reviewed By: hramos Differential Revision: D24004711 fbshipit-source-id: b682dd51fa998ee2e60f8d6ffd8c39220d13a7fe * TurboModule: exclude NativeSampleTurboModule in the schema Summary: The sample module is meant for demo only, but it lives alongside other core modules in react-native repo. For now, exclude it in the Flow-type parsing, just like `NativeUIManager.js` Changelog: [Internal] Reviewed By: hramos Differential Revision: D24005108 fbshipit-source-id: 9ef524bfe2778dd983c94d1701f9ce49da5e0a68 * Upgrade Robolectric from 4.3.1 -> 4.4 Summary: Changelog: [Internal] Reviewed By: jiawei-lyu Differential Revision: D23718455 fbshipit-source-id: 39c684722db1269e2179cf9680cb728be1171afb * TurboModule iOS: Remove module filters Summary: These native modules are now filtered downstream in `combine-js-to-schema-cli.js`. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24003572 fbshipit-source-id: d858dbf4a4b6d522ed528f9c2262f37243317160 * Fix React Native Robolectric 4.4 deps (#30073) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/30073 Changelog: [Android][Added] - Test infra: Robolectric 4.3.1 -> 4.4 upgrade Reviewed By: fkgozali Differential Revision: D24009953 fbshipit-source-id: 70549187f4af0abd2ea10f6725eecadbaef7281b * Drop old state updates Summary: Changelog: [internal] Components can update state multiple times before the state update queue is flushed. This causes unnecessary layout/diff and mount passes. To solve this, drop stale state updates inside `stateUpdateQueue_ ` for specific `ShadowNodeFamily`. Delivering stale status updates is redundant. Let's take SafeAreaView as an example. It schedules 5-6 state updates before `stateUpdateQueue_` is flushed. That's unnecessary work blocking JS thread. We only care about the latest state update. Same for TextInput and other components using state updates. Reviewed By: JoshuaGross Differential Revision: D23987707 fbshipit-source-id: 2e3f92cc93af61d78ac564aa40aef165af64b8c1 * Remove idx package from inspector msggen Summary: This was causing a crash in babel: ``` $ babel src --out-dir bin --source-maps Error: Cannot find module 'babel-plugin-idx' from '~/fbsource/xplat/js/react-native-github/ReactCommon/hermes/inspector/tools/msggen' - If you want to resolve "idx", use "module:idx" { code: 'MODULE_NOT_FOUND' } ``` It didn't appear that this module was used, so I deleted it. Changelog: [Internal] Reviewed By: neildhar Differential Revision: D23993272 fbshipit-source-id: dd34f0fc652cb27c87c891ca37d0eba66a19a6cf * iOS: fix ios-configure-glog.sh syntax issue Summary: A `cat` to file was removed accidentally, preventing the configuration script from executing successfully as part of a `pod install`. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24024824 fbshipit-source-id: 94af0c6e663320bfac04ee8f6fb37bd4bdc379a4 * chore: update RNTester example link in PanResponder comment (#30051) Summary: This PR fixes a small leftover after the RNTester migration to the monorepo package - an invalid link in the `PanResponder` comment. Refs: * https://github.com/facebook/react-native/issues/29567 * facebook/react-native-website#2177 (the similar correction was a part of merged PR in the RN docs) ## 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 --> [Internal][Fixed] PanResponder: correct example link in comment Pull Request resolved: https://github.com/facebook/react-native/pull/30051 Test Plan: N/A Reviewed By: fkgozali Differential Revision: D24025065 Pulled By: hramos fbshipit-source-id: 190486e458fb8e83a35fa2d3c62f4483f3a4334d * Android: removed Robolectric 4.3.1 Buck configuration Summary: It was recently upgraded to 4.4, so we don't need the 4.3.1 anymore. Changelog: [Android][Removed] Removed Robolectric 4.3.1 setup Reviewed By: jselbo Differential Revision: D24030822 fbshipit-source-id: 09b3c577d32028723e7bbc02f13459a7ae69b749 * Fixed incorrect assert in RCTScrollViewComponentView Summary: This diff removes an incorrect assert and replaces it with a debug-only verification phase that compares "what we want" with "what we get". Changelog: [Internal] Fabric-specific internal change. Reviewed By: PeteTheHeat Differential Revision: D23983123 fbshipit-source-id: 03a628b4f8baa1f5fe4b55354b7c943e38b5e537 * Update Android Gradle plugin to 4.0.1 (#29013) Summary: This is a major version update that needs to be tested thoroughly. Android Studio 4.0.1 is now available in the stable channel https://androidstudio.googleblog.com/2020/05/android-studio-40-available-in-stable.html https://developer.android.com/studio/releases/gradle-plugin#4.0.1 ## Changelog [Android] [Changed] - Update Android Gradle plugin to 4.0.1 Pull Request resolved: https://github.com/facebook/react-native/pull/29013 Test Plan: Build project Closes https://github.com/facebook/react-native/issues/29044 Reviewed By: shergin Differential Revision: D24041233 Pulled By: fkgozali fbshipit-source-id: 68ef0f313aa773866e65796e323ed0f19f41f834 * Log View hierarchy if removeViewAt crashes Summary: If removeViewAt crashes, log the children of the parent view, and all of the parent's ancestors. Changelog: [Internal] Reviewed By: shergin Differential Revision: D24019515 fbshipit-source-id: c5b1ca0948ebc47f2648e161770affa8542ca5dd * Deploy Flow v0.135.0 Summary: Changelog: [Internal] Reviewed By: mroch Differential Revision: D24040584 fbshipit-source-id: 106caa00cadd6930685c0030ad74685c64572ba9 * Update RNTester Podfile.lock * FIx Android patches * Back out "Align multi-line TextInput onSubmitEditing behavior" Summary: This is a revert of D22488870 (521b16730d). (https://github.com/facebook/react-native/pull/29177) We have to revert it because we realized that it's a breaking change without a very good reason. We have to figure out a better way to unify platform behaviors. Changelog: [iOS][Fixed] - Reverted recent change in TextInput (#29177) Reviewed By: fkgozali Differential Revision: D24200517 fbshipit-source-id: af0e561a6b8d9ade487be6b197a5d79d326442b6 * Add explanation for disabling @react-native/codegen/react-native-modules * Add TARGET_OS_OSX back to -textInputShouldReturn Co-authored-by: Samuel Susla <samuelsusla@fb.com> Co-authored-by: Valentin Shergin <shergin@fb.com> Co-authored-by: Jason Safaiyeh <safaiyeh@protonmail.com> Co-authored-by: Joshua Gross <joshuagross@fb.com> Co-authored-by: Ramanpreet Nara <ramanpreet@fb.com> Co-authored-by: Xuan Huang <jsx@fb.com> Co-authored-by: Rubén Norte <rubennorte@fb.com> Co-authored-by: Riley Dulin <dulinr@fb.com> Co-authored-by: Michel Weststrate <mweststrate@fb.com> Co-authored-by: Kevin Gozali <fkg@fb.com> Co-authored-by: Mike Vitousek <mvitousek@fb.com> Co-authored-by: generatedunixname89002005287564 <generatedunixname89002005287564@fb.com> Co-authored-by: Andrei Shikov <ashikov@fb.com> Co-authored-by: Agastya Darma <gedeagas22@gmail.com> Co-authored-by: Scott Kyle <skyle@fb.com> Co-authored-by: Makar Kotlov <m.kotlov@qlean.ru> Co-authored-by: chirag-singhal <csinghal208@gmail.com> Co-authored-by: grabbou <grabbou@gmail.com> Co-authored-by: Emily Janzer <janzer@fb.com> Co-authored-by: Eloy Durán <eloy.de.enige@gmail.com> Co-authored-by: Luna Wei <luwe@fb.com> Co-authored-by: Ankit Tiwari <ankitt255@gmail.com> Co-authored-by: Stanisław Chmiela <sjchmiela@users.noreply.github.com> Co-authored-by: Lulu Wu <luluwu@fb.com> Co-authored-by: Peter Argany <petetheheat@fb.com> Co-authored-by: Paige Sun <paigesun@fb.com> Co-authored-by: Michael Yoon (LAX) <mikeyoon@fb.com> Co-authored-by: Rob Walker <rob@papertrail.io> Co-authored-by: Janic Duplessis <janicduplessis@gmail.com> Co-authored-by: Martin Ortega <martega@fb.com> Co-authored-by: Tim Yung <yungsters@fb.com> Co-authored-by: simek <gosimek@gmail.com> Co-authored-by: generatedunixname89002005325676 <generatedunixname89002005325676@fb.com> Co-authored-by: Tommy Nguyen <tonguye@microsoft.com> Co-authored-by: Joshua Selbo <jselbo@fb.com> Co-authored-by: Héctor Ramos <hramos@fb.com> Co-authored-by: Frieder Bluemle <frieder.bluemle@gmail.com> Co-authored-by: Sam Goldman <samgoldman@fb.com>		2021-09-28 09:57:51 -07:00
..
Batchinator-test.js	Migrate "Libraries" from Haste to standard path-based requires (sans vendor & renderers) (#24749)	2019-05-08 08:48:59 -07:00
InteractionManager-test.js	Merge react-native 0.61-stable (#323)	2020-04-28 11:49:15 -07:00
InteractionMixin-test.js	Migrate "Libraries" from Haste to standard path-based requires (sans vendor & renderers) (#24749)	2019-05-08 08:48:59 -07:00
TaskQueue-test.js	Merge from upstream through 2020-09-30 (#833)	2021-09-28 09:57:51 -07:00