Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release build of Hermes + ProGuard crashes on 0.62.0-rc.5 #28270

Closed
hsjoberg opened this issue Mar 9, 2020 · 7 comments
Closed

Release build of Hermes + ProGuard crashes on 0.62.0-rc.5 #28270

hsjoberg opened this issue Mar 9, 2020 · 7 comments
Labels
Needs: Triage 🔍 Platform: Android Android applications. Resolution: Locked This issue was locked by the bot.

Comments

@hsjoberg
Copy link
Contributor

hsjoberg commented Mar 9, 2020

When building a release version of Android with Hermes and ProGuard enabled, it instantly crashes on 0.62.0-rc.5.

In the log I see the following:

About to load: libhermes.so
libhermes.so not found on /data/data/com.rn062/lib-main
libhermes.so found on /data/app/com.rn062-Fjs_ZyNxAT33Mc4PFvqS7Q==/lib/x86
Not resolving dependencies for libhermes.so

React Native version:

0.62.0-rc.5

Steps To Reproduce

This is tested on Linux (PureOS, basically Debian).

  1. Create a new project npx react-native init RN062 --version 0.62.0-rc.5
  2. Enable Hermes and ProGuard in android/app/build.gradle
  3. Add Hermes exception in android/app/proguard-rules.pro:
    -keep class com.facebook.hermes.unicode.** { *; }
  4. Run npx react-native run-android --variant release. The app will instantly crash.

Expected Results

The app to function properly

Snack, code example, screenshot, or link to a repository:

Crash happens on create react native app template.

@hsjoberg hsjoberg changed the title Release build of Hermes + ProGuard crashes on 0.62.0-rc.5. Release build of Hermes + ProGuard crashes on 0.62.0-rc.5 Mar 9, 2020
@kelset kelset added the Platform: Android Android applications. label Mar 9, 2020
@willholen
Copy link
Contributor

It's failing to find com.facebook.jni.NativeRunnable. It appears to work if you add -keep class com.facebook.jni.** { *; }

@hsjoberg
Copy link
Contributor Author

Yes adding -keep class com.facebook.jni.** { *; }to android/app/proguard-rules.pro fixes the problem for me!

@hsjoberg
Copy link
Contributor Author

hsjoberg commented Mar 10, 2020

Opened a PR for the website: facebook/react-native-website#1715

@hsjoberg
Copy link
Contributor Author

Closing this one as PR got merged in website repo.

@matt-oakes
Copy link
Contributor

Should the new proguard rule have gone into React Native's proguard-rules.pro file so users wouldn't need to add it to their own?

radko93 added a commit to radko93/react-native that referenced this issue Apr 9, 2020
This adds a ProGuard so users don't have to add it manually. facebook#28270
@radko93
Copy link
Contributor

radko93 commented Apr 9, 2020

@matt-oakes @Maskedman99 @alloy I created a PR for that #28571. But I'm not sure if people will be happy if we don't strip this when they don't use hermes

@matt-oakes
Copy link
Contributor

@radko93 I see what you mean, but given that a lot of React Native developers have very limited experience with native tooling like ProGuard, I would suggest making the default as simple as possible. Especially as the issue won't show up until the use creates a release build and runs that, which might not happen until it's been published.

facebook-github-bot pushed a commit that referenced this issue Apr 9, 2020
Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
#28270

## 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] - ProGuard rule for hermes
Pull Request resolved: #28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d
grabbou pushed a commit that referenced this issue Jul 14, 2020
Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
#28270

## 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] - ProGuard rule for hermes
Pull Request resolved: #28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d
amgleitman added a commit to microsoft/react-native-macos that referenced this issue Jul 14, 2021
* Update default Podfile to not depend on a path (facebook#28572)

Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.

While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.

https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9

Unfortunately, due to the way Ruby works, this completely hides the path away from the users.

Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.

With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.

https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10

This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.

As a result, we don't have to change the paths here whether we're running monorepo or not.

## Changelog

[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: facebook#28572

Differential Revision: D20945194

Pulled By: TheSavior

fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27

* Upgrade Prettier in Xplat to version 1.19.1

Summary:
Upgrades Prettier in Xplat to 1.19.1
Ignores upgrading packages on already on versions greater than 1.19.1

Changelog: [Internal]

allow-large-files
bypass-lint

(Note: this ignores all push blocking failures!)

Reviewed By: gkz, cpojer

Differential Revision: D20879147

fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d

* Stop using get_fbobjc_enable_exception_lang_compiler_flags_DEPRECATED in xplat

Summary:
Old deprecated function.

Changelog: [Internal]

Reviewed By: nlutsenko

Differential Revision: D20148856

fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469

* Add ProGuard rule for hermes (facebook#28571)

Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
facebook#28270

## 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] - ProGuard rule for hermes
Pull Request resolved: facebook#28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d

* Move CheckBox JS files to FB Internal

Summary:
Move CheckBox JS files to FB internal

## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D20910775

fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327

* Remove CheckBox from docsList.js

Co-authored-by: Mike Grabowski <grabbou@gmail.com>
Co-authored-by: George Zahariev <gkz@fb.com>
Co-authored-by: Scott Wolchok <swolchok@fb.com>
Co-authored-by: Radek Czemerys <radko93@gmail.com>
Co-authored-by: Lauren Tan <laurentan@fb.com>
amgleitman added a commit to microsoft/react-native-macos that referenced this issue Jul 21, 2021
* Update default Podfile to not depend on a path (#28572)

Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.

While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.

https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9

Unfortunately, due to the way Ruby works, this completely hides the path away from the users.

Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.

With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.

https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10

This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.

As a result, we don't have to change the paths here whether we're running monorepo or not.

## Changelog

[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: https://github.com/facebook/react-native/pull/28572

Differential Revision: D20945194

Pulled By: TheSavior

fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27

* Upgrade Prettier in Xplat to version 1.19.1

Summary:
Upgrades Prettier in Xplat to 1.19.1
Ignores upgrading packages on already on versions greater than 1.19.1

Changelog: [Internal]

allow-large-files
bypass-lint

(Note: this ignores all push blocking failures!)

Reviewed By: gkz, cpojer

Differential Revision: D20879147

fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d

* Stop using get_fbobjc_enable_exception_lang_compiler_flags_DEPRECATED in xplat

Summary:
Old deprecated function.

Changelog: [Internal]

Reviewed By: nlutsenko

Differential Revision: D20148856

fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469

* Add ProGuard rule for hermes (#28571)

Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
https://github.com/facebook/react-native/issues/28270

## 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] - ProGuard rule for hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d

* Move CheckBox JS files to FB Internal

Summary:
Move CheckBox JS files to FB internal

## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D20910775

fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327

* fix: ripple should be applied even when borderless == false (#28526)

Summary:
With current master, when you render `<Pressable android_ripple={{borderless: false}}>`, there is no ripple effect at all.

I think the expected behavior is to have ripple with default color and radius, just not borderless.

This was how it was done (by me) in https://github.com/facebook/react-native/pull/28156/files but in the import process, the implementation was changed: https://github.com/facebook/react-native/commit/bd3868643d29e93610e19312571a9736df2cbdf8 so either this PR is a fix or you can just close it (but I'd be curious why).

## 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] [fixed] - ripple should be applied even when borderless == false
Pull Request resolved: https://github.com/facebook/react-native/pull/28526

Test Plan:
`<Pressable android_ripple={{borderless: false}}>` on master

![SVID_20200404_123614_1](https://user-images.githubusercontent.com/1566403/78424971-6b315a80-7671-11ea-8be4-5fea428bc556.gif)

`<Pressable android_ripple={{borderless: false}}>` in this PR

![SVID_20200404_122754_1](https://user-images.githubusercontent.com/1566403/78424986-8bf9b000-7671-11ea-9804-37cd58dbb61e.gif)

Differential Revision: D20952026

Pulled By: TheSavior

fbshipit-source-id: df2b95fc6f20d7e958e91805b1a928c4f85904f1

* Remove ColorAndroid function as it adds no value over PlatfromColor (#28577)

Summary:
This change removes the `ColorAndroid` API.   It was added more as a validation tool than as something useful to a developer.   When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc.    Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`.    Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.

## 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] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577

Test Plan: RNTester in both iOS and Android was tested.   Jest tests, Flow checks, Lint checks all pass.

Reviewed By: cpojer

Differential Revision: D20952613

Pulled By: TheSavior

fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0

* iOS: mark some old NativeModule targets with depslint_never_remove

Summary:
Label some BUCK targets properly.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D20960917

fbshipit-source-id: 42fa2266105b6c3dd5108a1b56035a19a95cd61f

* Update Gradle Wrapper to 6.3 (#28173)

Summary:
```
Welcome to Gradle 6.3!

Here are the highlights of this release:
 - Java 14 support
 - Improved error messages for unexpected failures

For more details see https://docs.gradle.org/6.3/release-notes.html
```

## Changelog

[Android] [Changed] - Update Gradle Wrapper to 6.3
Pull Request resolved: https://github.com/facebook/react-native/pull/28173

Test Plan: Build project

Differential Revision: D20958894

Pulled By: mdvacca

fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f

* Fix crash inside RCTRedBox when trying to present same UIViewController twice

Summary:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash

We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:

> A Boolean value indicating whether the view controller is being presented.

Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#

 ---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.

```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```

Changelog: Fix crash caused by presenting view controller twice from RCTRedBox

Reviewed By: PeteTheHeat

Differential Revision: D20946645

fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81

* Animated: Early detection of division by zero in AnimatedDivision

Summary:
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] Early crash in AnimatedDivision in case of division by zero.

Reviewed By: mdvacca

Differential Revision: D20969087

fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344

* Fabric: Controlling DifferentiatorMode via ReactNativeConfig

Summary:
Now we can control the differentiator mode via MC.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: fkgozali

Differential Revision: D20978857

fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4

* Upgrade Hermes dependency to 0.5.0

Summary:
Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`.

Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0

allow-large-files

Reviewed By: mhorowitz

Differential Revision: D20998564

fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50

* Set width/height also to Undefined when we change the measure mode to Undefined

Summary:
Make sure width/height is always passed as Undefined when measure mode is changed to Undefined.

Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined

Reviewed By: alickbass

Differential Revision: D20029838

fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304

* Remove redundant input from TextInput

Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D21016502

fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088

* Update RNTester AppDelegate for changes made to SurfacePresenter API (#28580)

Summary:
This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`.

## Changelog

[Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/28580

Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled.

Reviewed By: hramos

Differential Revision: D20966067

Pulled By: mdvacca

fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1

* Retryable ViewCommand exceptions shouldn't crash

Summary:
Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing).

Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow.

If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely.

The only concern I have with landing this is the perf implications of putting a try/catch inside this loop.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21023213

fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82

* Remove setMostRecentEventCount from TextInput view commands

Summary:
Changelog: [Internal]

We don't use view command `setMostRecentEventCount`, let's get rid of it.

Reviewed By: JoshuaGross

Differential Revision: D21016600

fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b

* label-actions: Add canned response for upgrade issues

Summary:
Enhance the label-actions config and support a "Type: Upgrade Issue" label.
- Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied.
- Close the issue.

Changelog:
[Internal] label-actions: Add canned response for upgrade issues

Reviewed By: cpojer

Differential Revision: D20974607

fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56

* Yoga Podspec: Export YGNode and YGStyle headers (#997)

Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.

The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.

This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.

I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.

Changelog:

[Internal] - Yoga Podspec: Export YGNore and YGStyle headers

Pull Request resolved: https://github.com/facebook/yoga/pull/997

Reviewed By: hramos

Differential Revision: D20966075

Pulled By: mdvacca

fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e

* Add logging to catch null TurboModules

Summary:
We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027984

fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6

* Remove module cache from ReactPackageTurboModuleManagerDelegate

Summary:
This cache is unnecessary, because:
1. TurboModuleManager caches all created TurboModules
2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`.

This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027998

fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7

* Control concurrent calls into TMMDelegate from TMM

Summary:
In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created.

## The problem:
What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees.

## The fix
`TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood).

Changelog:
[Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager

Reviewed By: mdvacca

Differential Revision: D21025965

fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df

* Bump eslint-plugin-react-native-community version to 1.1.0

Summary:
This release will include the new platform-colors rule.

Changelog: [Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21022163

fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7

* Update Babel to 7.8.x/7.9.x

Reviewed By: motiz88

Differential Revision: D20697095

fbshipit-source-id: ef35d02da0916109ce528d3026f7ca0956911dda

* fix: do not throw on missing `cliPath`, use the default value (#28625)

Summary:
The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file.

In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change.

## Changelog

[ANDROID] [INTERNAL] - Don't require `cliPath`
Pull Request resolved: https://github.com/facebook/react-native/pull/28625

Test Plan:
Run Android project, everything works.
Provide custom `cliPath`, it gets respected

Reviewed By: cpojer

Differential Revision: D21044222

Pulled By: TheSavior

fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e

* Fix CIRCLE_PR_NUMBER may not always be set (#28640)

Summary:
This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork.

## Changelog

[Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set
Pull Request resolved: https://github.com/facebook/react-native/pull/28640

Test Plan: Report bundle size step should pass on both this PR and https://github.com/facebook/react-native/issues/28641.

Reviewed By: cpojer

Differential Revision: D21045553

Pulled By: TheSavior

fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608

* Add "Open Debugger" and "Open React DevTools" to iOS dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D20784270

fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd

* Changed iOS LaunchScreen from xib to storyboard (#28239)

Summary:
> Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens.

Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b).

Community discussion: https://github.com/react-native-community/discussions-and-proposals/issues/209

## Changelog

Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required.

[iOS] [Deleted] - Deleted LaunchScreen.xib
[iOS] [Added] - Added LaunchScreen.storyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/28239

Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one.

Reviewed By: cpojer

Differential Revision: D20408892

Pulled By: hramos

fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a

* Switch over to JavaTurboModule::InitParams

Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).

**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.

## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
 public:
  struct InitParams {
    std::string moduleName;
    jni::alias_ref<JTurboModule> instance;
    std::shared_ptr<CallInvoker> jsInvoker;
    std::shared_ptr<CallInvoker> nativeInvoker;
  };
```

All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments.  Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.

## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.

## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.

## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.

## Commands run

Reviewed By: fkgozali

Differential Revision: D21035208

fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c

* RN: Shrinkwrap Text Layout (Android)

Summary:
When text is in a constrained parent view using `maxWidth`, long text may wrap. When the text wraps, the final width is dependent on the word breaking strategy and text content. This means that the text width is not necessarily `maxWidth`.

However, the current way that we compute text layout does not shrinkwrap the text width as much as possible. This leads to visual gaps to the end-side of wrapped text.

This changes the text layout slightly so that we use the length of the longest line.

This bug only exists on Android. After this change, Android behaves like iOS.

Changelog:
[Android] [Fixed] - Fixed excessive space in Text view with word-wrapping

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21056031

fbshipit-source-id: e9b7793f2632caafcce69bc15bac61330b0ed958

* (eslint-config) update community eslint plugin in eslint config (#28642)

Summary:
Updating the community eslint-plugin used in the eslint-config to the latest version.

expecting new eslint-config version to be released with this change so that it can be included in new project template for 0.63 https://github.com/react-native-community/releases/issues/186

## 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 community eslint plugin in the eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/28642

Test Plan: yarn lint passes

Differential Revision: D21048976

Pulled By: cpojer

fbshipit-source-id: 2c3ec0ef450cf357d8c88db7873f4ca1154b2034

* chore: update CLI to the latest version (#28623)

Summary:
Bumps CLI to the latest version, needed by https://github.com/facebook/react-native/pull/28572 to work.

## Changelog

[INTERNAL] - Bump CLI to latest
Pull Request resolved: https://github.com/facebook/react-native/pull/28623

Reviewed By: hramos

Differential Revision: D21017766

Pulled By: cpojer

fbshipit-source-id: 62a873923c58f8752edb0394db7e6dfceed92485

* Add "Open Debugger" and "Open React DevTools" to Android dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20784279

fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb

* Remove the post install step (#28651)

Summary:
Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5.

cc alloy

## 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
-->

[Flipper] [Template] - Remove the post install step for Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/28651

Test Plan: Tested a newly created RN app without post install step and it built successfully.

Reviewed By: passy

Differential Revision: D21064653

Pulled By: priteshrnandgaonkar

fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac

* Revert D21064653: Remove the post install step

Differential Revision:
D21064653

Original commit changeset: da56d0754d91

fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124

* Remove out of date TODO

Summary:
No longer relevant.

Changelog: [Internal]

Reviewed By: mhorowitz

Differential Revision: D21070955

fbshipit-source-id: 11b0384501b2780f5ac41899b5e8bbb4f7a4d730

* RNTester LayoutAnimation example: add more options

Summary:
Add more options to the LayoutAnimation example so it's easier to test more features of LayoutAnimations.

1) Add an option to animate reordering of views
2) Make animations slower, so it's easier to see what's going on and easier to trigger race conditions
3) Add options to mutate without animation, to test interrupting existing animations

Changelog: [Internal] Updated Catalyst RNTester LayoutAnimation example with additional options

Reviewed By: mdvacca

Differential Revision: D21050309

fbshipit-source-id: 1daba4fd487693c34a2d40eb39a68c7d03c24f93

* Add a "reparenting" LayoutAnimation example that animates flattening/unflattening

Summary:
Simple test to see what it looks like when view flattening/unflattening is animated with LayoutAnimations.

Changelog: [Internal] adding another example to LayoutAnimations example

Reviewed By: mdvacca

Differential Revision: D21074805

fbshipit-source-id: 551ed740f0ab5c5adcb19f5c35e932b8983cd108

* Fix jsi cmake include dirs (#207)

Summary:
I'm trying to use JSI for a React Native custom module. I saw these existing examples where the JSI API is used in the context of a CMakeLists.txt:
https://github.com/terrysahaidak/host-object-test/blob/master/libs/android-jsi/test-jsi/src/main/cpp/CMakeLists.txt
https://github.com/ericlewis/react-native-hostobject-demo/pull/4/files#diff-834320be1b4e4016bac27c05dcd17fb9
In both cases, they manually grab the include directories and jsi.cpp from node_modules/react-native, but I also saw that node_modules/react-native/ReactCommon/jsi/jsi already has a CMakeLists.txt that appears to be intended to provide a jsi static lib, so I tried to pull this into my own CMakeLists.txt like this:
```
add_subdirectory(${RN_DIR}/ReactCommon/jsi/jsi ${CMAKE_CURRENT_BINARY_DIR}/jsi)
...
target_link_libraries(MyLib jsi)
```
Unfortunately when doing this, the consuming project still doesn't see the correct include directories. The change I'm proposing here is to use `target_include_directories` and declare that `..` is a public (to consumers) include directory for the library named `jsi`. With this change, you can do what I showed above to consume the jsi lib by just pulling in the CMakeLists.txt file into your own CMakeLists.txt file.

Changelog: [General][Fixed] Fix jsi cmake include dirs

Pull Request resolved: https://github.com/facebook/hermes/pull/207

Reviewed By: willholen

Differential Revision: D21074270

Pulled By: tmikov

fbshipit-source-id: 7d9ec3255f57a16c0b2be489dffa4540727738a1

* Resolve `kind-of` vulnerability by bumping to 6.0.3

Summary:
https://github.com/advisories/GHSA-6c8f-qphg-qjgp

Changelog:
[General][Changed] Updated transitive dependency kind-of to 6.0.3 to resolve vulnerability

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21077747

fbshipit-source-id: d5c19b21b665130c6423f5caeddcd6378bac7dcb

* Move CheckBox Android files to FB internal (#28658)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28658

This moves the Java files to FB internal and updates all the buck files.

## Changelog:

[Android] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D21066998

fbshipit-source-id: 76821fcae899ff7342697ea7dd4737ef3b008213

* Part 1: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.

## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.

## Commands run
```
function update-codegen() {
  pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}

> update-codegen
```

Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036266

fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086

* Part 2: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035209.

## Changes
- Codemod all ObjC NativeModule `getTurboModuleWithJsInvoker:nativeInvoker:perfLogger` methods to `getTurboModule:(const ObjCTurboModule::Args)`

## Script
```
var withSpaces = (...args) => args.join('\s*')

var regexString = withSpaces(
  '-',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<turboModuleClass>(facebook::react::|react::|::|)TurboModule)',
  '>',
  '\)',
  'getTurboModuleWithJsInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<fbNamespace>(facebook::react::|react::|::|))CallInvoker',
  '>',
  '\)',
  '(?<jsInvokerInstance>[A-Za-z0-9]+)',
  'nativeInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(facebook::react::|react::|::|)CallInvoker',
  '>',
  '\)',
  '(?<nativeInvokerInstance>[A-Za-z0-9]+)',
  'perfLogger',
  ':',
  '\(',
  'id',
  '<',
  'RCTTurboModulePerformanceLogger',
  '>',
  '\)',
  '(?<perfLoggerInstance>[A-Za-z0-9]+)',
  '{',
  'return',
  'std::make_shared',
  '<',
  '(?<specName>(facebook::react::|react::|::|)Native[%A-Za-z0-9]+SpecJSI)',
  '>',
  '\(',
  'self',
  ',',
  '\k<jsInvokerInstance>',
  ',',
  '\k<nativeInvokerInstance>',
  ',',
  '\k<perfLoggerInstance>',
  '\)',
  ';',
  '}',
)

var replaceString = `- (std::shared_ptr<$<turboModuleClass>>) getTurboModule:(const $<fbNamespace>ObjCTurboModule::InitParams &)params
{
  return std::make_shared<$<specName>>(params);
}`

const exec = require('../lib/exec');
const abspath = require('../lib/abspath');
const relpath = require('../lib/relpath');
const readFile = (filename) => require('fs').readFileSync(filename, 'utf8');
const writeFile = (filename, content) => require('fs').writeFileSync(filename, content);

function main() {
  const tmFiles = exec('cd ~/fbsource && xbgs -n 10000 -l getTurboModuleWithJsInvoker:').split('\n').filter(Boolean);

  tmFiles
    .filter((filename) => !filename.includes('microsoft-fork-of-react-native'))
    .map(abspath)
    .forEach((filename) => {
      const source = readFile(filename);
      const newSource = source.replace(new RegExp(regexString, 'g'), replaceString);

      if (source == newSource) {
        console.log(relpath(filename));
      }

      writeFile(filename, newSource);
    });
}

if (!module.parent) {
  main();
}
```

## Re-generating diff
```
> hg revert -r .^ --all
> node index.js # run script
```

Changelog: [iOS][Changed] - Make all ObjC NativeModules create TurboModules using ObjCTurboModule::Args

Reviewed By: PeteTheHeat

Differential Revision: D21036265

fbshipit-source-id: 404bcc548d1775ef23d793527606d02fe384a0a2

* Part 3: Update RCTTurboModuleManagerDelegate to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- Update `RCTTurboModuleManagerDelegate getTurboModule:instance:jsInvoker:nativeInvoker:perfLogger` to use `RCTTurboModuleManagerDelegate getTurboModule:(const ObjCTurboModule::InitParams)`
- Update all implementations of `RCTTurboModuleManagerDelegate` in accordance with this API change

Changelog:
[iOS][Changed] - Make RCTTurboModuleManagerDelegate create TurboModules via ObjCTurboModuleManager::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036272

fbshipit-source-id: c16002c47db26e2ba143fc1080afe9e2fe1e7816

* chore: update `./scripts/test-manual-e2e.sh` (#28653)

Summary:
Recent changes broke the script - wrong path to open `RNTesterPods.xcworkspace` and other scripts - we change dir with `cd`.

Another change is incorrect use of `RNTesterProject.xcodeproj` instead of a `xcworkspace`.

This PR is a simple and short fix to make it run.

## Changelog

[INTERNAL] - chore: update `./scripts/test-manual-e2e.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/28653

Test Plan: Run `./scripts/test-manual-e2e.sh`. Things work.

Differential Revision: D21079792

Pulled By: hramos

fbshipit-source-id: 6bdb8be016f044852ed216ec53f80db40c84b5fd

* use default value of enums YGDirection and YGMeasureMode instead of -1

Summary:
Changelog:
[Internal][Yoga] YGDirection variable was initialized incorrectly by casting -1 to YGDirection. Changing it to default value of direction

Same for YGMeasureMode.

Reviewed By: pasqualeanatriello

Differential Revision: D20869042

fbshipit-source-id: 7bfe490193321baae875ef6fb49a938851950c9f

* fix typo as there is no file called YGJNI.cpp (#990)

Summary:
fix typo in `YogaJNIBase.java` as there is no such file called `YGJNI.cpp`
Pull Request resolved: https://github.com/facebook/yoga/pull/990

Reviewed By: pasqualeanatriello

Differential Revision: D20735102

Pulled By: SidharthGuglani

fbshipit-source-id: 3f9f4d78ba390feae3451330f997a221ab4ec70e

* Remove unused packages from xplat/js/package.json

Summary:
We have a large amount of small packages that are completely unused, or only have one call site. This diff cleans up a lot of them and reduces node_modules by 12 MiB (down to 187).

Changelog: [Internal]

Reviewed By: motiz88

Differential Revision: D21088213

fbshipit-source-id: 5fa7d3da5cbe744b0d9d3e3450d6135c1488ee79

* Make ColorValue public in StyleSheet.js

Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.

Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet

Reviewed By: TheSavior

Differential Revision: D21076969

fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab

* Fabric: `LayoutableShadowNode:getLayoutMetrics` is not a virtual method anymore

Summary:
We don't use it as vitrual anymore (setLayoutMetrics is a non-virtual method already), so it does not need to be marker virtual.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028572

fbshipit-source-id: 99f86fdd4cf2f5972034d9058d7b82bdc8680187

* Fabric: Proper traits for `ImageShadowNode` and `ViewShadowNode`

Summary:
* <Image> must be a leaf node; having a proper trait will fail earlier in case of misuse (mounting something inside).
* <View> must have a `View` trait because it's for what that trait is.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D21028573

fbshipit-source-id: 457716d4661333eb2357f34316f3e495ab4fda24

* Fabric: "Attempt to mutate a sealed object." is now an assert (not exception)

Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028571

fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9

* Fabric: Implementation of `getDebugDescription` for `std::array`

Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028570

fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd

* Fabric: `componentregistry` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885163

fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af

* Fabric: `scheduler` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885645

fbshipit-source-id: 8148bd934879802b076261ed86fa78acf0a07ed3

* Fabric: `templateprocessor` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885646

fbshipit-source-id: b8e3199c0eacc57a5be1481595cf97c84f972293

* Migrate deprecated frameInterval to preferredFramesPerSecond (#28675)

Summary:
[frameInterval](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval) was deprecated in favor of [preferredFramesPerSecond](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1648421-preferredframespersecond).

This migrates the deprecated call over.

## 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
-->

[iOS] [Fixed] - Migrate frameInterval to preferredFramesPerSecond
Pull Request resolved: https://github.com/facebook/react-native/pull/28675

Test Plan: Xcode should no longer throw warnings about the deprecated call.

Differential Revision: D21109710

Pulled By: shergin

fbshipit-source-id: 772b9f625d3e22cd4d8cd60bddad57ff8611af54

* Fabric: Fix case of Glog include in MountingTest.cpp (#28616)

Summary:
This pull request changes the include of Glog from `<Glog/logging.h>` to `<glog/logging.h>` in `MountingTest.cpp`. This fixes building on a case-sensitive filesystem.

## Changelog

[Internal] [Fixed] - Fabric: Fix case of Glog include in MountingTest.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/28616

Test Plan: The `include` of Glog no longer causes issues with building `MountingTest.cpp` on a case-sensitive filesystem.

Differential Revision: D21118085

Pulled By: shergin

fbshipit-source-id: c958c54bf88333fd5001127779c855ce8c2666c3

* Fabric: Add Unicode prefix to AttachmentCharacter (#28617)

Summary:
This pull request adds a Unicode `u8` prefix to the string literal returned in `AttributedString.cpp`'s `Fragment::AttachmentCharacter()`.

This fixes the following error when building on MSVC:

```
react\attributedstring\AttributedString.cpp(21): error C4566: character represented by universal-character-name '\uFFFC' cannot be represented in the current code page (1252)
```

## Changelog

[Internal] [Fixed] - Fabric: Add Unicode prefix to AttachmentCharacter
Pull Request resolved: https://github.com/facebook/react-native/pull/28617

Test Plan: The Fabric test suite has been ran on a Clang-based build of Fabric on macOS, and no regressions in it have been noted.

Differential Revision: D21118078

Pulled By: shergin

fbshipit-source-id: c105de5e4edb67fed97ce44153a75d9d380bf588

* Fabric: Fixed incorrect early-return in `UIView+ComponentViewProtocol::updateLayoutMetrics`

Summary:
Before the change, an incorrect (NaN or Inf) values in LayoutMetrics might force an early return in the `updateLayoutMetrics:oldMetrics:` method implementation. This was not correct because the rest of the method also didn't run in this case, so it might force some value to stale.
E.g., imagine we have an instruction that contains NaN size and `display: none`. Previously, the function might just return right before applying sizes and progress the stored "already applied" value of LayoutMetrics which will cause the view being visible even if it should not.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110644

fbshipit-source-id: 501319d7b1dcd5c18f27e0ceca3c8d207485c49b

* Fix border-stroke drawing after resetting border-radius (#28356)

Summary:
This PR fixes incorrect drawing of the View borders on Android, after changing the border-radius back to 0 *(and when no background-color is defined)*.

This happens because the `drawRoundedBackgroundWithBorders` function in ReactViewBackgroundDrawable changes the style on the Paint object to `STROKE`. This style is however never reverted back to `FILL`. This change ensures that the Paint style is set to `FILL` for the full execution of the `drawRectangularBackgroundWithBorders` function.

## Changelog

`[Android] [Fixed] - Fix border-drawing when changing border-radius back to 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28356

Test Plan:
**Faulty situation:**

![ezgif com-video-to-gif](https://user-images.githubusercontent.com/6184593/77153163-9759b280-6a99-11ea-82bb-33a1e0a4934c.gif)

**After the fix:**

![ezgif com-video-to-gif (1)](https://user-images.githubusercontent.com/6184593/77153825-c91f4900-6a9a-11ea-8e0c-a4280b9e72b8.gif)

Differential Revision: D21124741

Pulled By: shergin

fbshipit-source-id: 2044f8e8ad59a58df42b64d7ee8c4ad1d3b562f1

* Fabric: Using proper clock in MountingTelemetryTest

Summary:
Apparently, `std::this_thread::sleep_for` uses a different clock to measure time which causes ofter misalignment with the clock which Telemery uses which makes the test flaky. Using the same clock should fix it.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21116058

fbshipit-source-id: 52dde2e325776d365431a2a957dcc12dfe53f890

* Fix rounded border drawing when border-radius is smaller than border-width (#28358)

Summary:
This PR fixes the drawing of the border rounded edges when the border-radius is small than the border-width. The current implementation capped the possible border-radius making it impossible to set smaller border-radii when using thicker borders. After inspection it was found that the rounded-rect calculation is incorrect.

## Changelog

`[Android] [Fixed] - Fix rounded border-drawing when border-radius is smaller than border-width`
Pull Request resolved: https://github.com/facebook/react-native/pull/28358

Test Plan:
**Faulty situation:**

As you can see, when the border-radius becomes very low, the border is stuck at a minimum value. Only after setting the border-radius fully to 0 is it again rendered correctly.

![ezgif com-video-to-gif (2)](https://user-images.githubusercontent.com/6184593/77183540-c3435b00-6ace-11ea-950d-29a0ea1757bd.gif)

**After the fix:**

![ezgif com-video-to-gif (3)](https://user-images.githubusercontent.com/6184593/77183619-e837ce00-6ace-11ea-93a5-910127d352b7.gif)

Differential Revision: D21124739

Pulled By: shergin

fbshipit-source-id: cefd1776b77b5b9fb335e95fd7fdd7f345579dc4

* Fabric: `ComponentDescriptor::cloneProps()` now never returns the base props objects

Summary:
The diff changes how the `empty raw props` optimization works in `ComponentDescriptor::cloneProps()`. Now it only fires only when the base `props` object is null, which is practically all production cases we have (and care about). (I tried, in a normal run there were no cases where the empty raw props were passed with non-null props.) From the other side, the old behavior that may return the same props objects previously several times created bugs and practically unexpected results and practically disallowed to clone props objects easily.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110608

fbshipit-source-id: 884807cd8e9c5c3e6cc1c9e4c1f0227259cc21fb

* Upgrade to Jest 25

Summary:
This diff upgrades Jest to the latest version which fixes a bunch of issues with snapshots (therefore allowing me to enable the Pressable-test again). Note that this also affects Metro and various other tooling as they all depend on packages like `jest-worker`, `jest-haste-map` etc.

Breaking changes: https://github.com/facebook/jest/blob/master/CHANGELOG.md

This diff increases node_modules by 3 MiB, primarily because it causes more duplicates of `source-map` (0.8 MiB for each copy) and packages like `chalk` 3.x (vs 2.x). The base install was 15 MiB bigger and I reduced it to this size by playing around with various manual yarn.lock optimizations. However, D21085929 reduces node_modules by 11 MiB and the Babel upgrade reduced node_modules by 13 MiB. I will subsequently work on reducing the size through other packages as well and I'm working with the Jest folks to get rid of superfluous TypeScript stuff for Jest 26.

Other changes in this diff:
* Fixed Pressable-test
* Blackhole node-notifier: It's large and we don't need it, and also the license may be problematic, see: https://github.com/facebook/jest/pull/8918
* Updated jest-junit (not a Jest package) but blackholed it internally because it is only used for open source CI.
* Updated some API calls we use from Jest to account for breaking changes
* Made two absolutely egrigious changes to existing product code tests to make them still pass as our match of async/await, fake timers and then/promise using `setImmediate` is tripping up `regenerator` with `Generator is already run` errors in Jest 25. These tests should probably be rewritten.
* Locked everything to the same `resolve` version that we were already using, otherwise it was somehow pulling in 1.16 even though nothing internally uses it.

Changelog: [General] Update Jest

Reviewed By: rickhanlonii

Differential Revision: D21064825

fbshipit-source-id: d0011a51355089456718edd84ea0af21fd923a58

* Apply placeholderColor to TextInput component

Summary:
Changelog: [Internal]

TextInput's `placeholderTextColor` prop was being ignored. This diff fixes that.

Reviewed By: JoshuaGross

Differential Revision: D21064118

fbshipit-source-id: 33f148c355cee846db010153e0c65ea43155c3c9

* Fix mistake in swapping left/right layout properties

Summary:
Changelog: [Internal]

We were assigned `undefined` value to incorrect edge, instead of `YGEdgeLeft` it should have been `YGEdgeRight`.
If node has `YGEdgeRight` value, it needs to be reassigned to `YGEdgeEnd` and its original value set to undefined.

Reviewed By: mdvacca

Differential Revision: D21095234

fbshipit-source-id: fbecd9b7e6670742ad4a4bb097760aa10eec8685

* Fixed incorrect owner assignment in YGNode move constructor

Summary:
Assigning self as an owner makes a cycle which is obviously a bug.

Changelog: [Internal] Small change in Yoga (should not affect RN).

Reviewed By: SidharthGuglani

Differential Revision: D21111423

fbshipit-source-id: 1835561c055ac827f5ce98a044f25aed0d1845a5

* Easy diff to add a TODO

Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands

This was orginally added D17142507

changelog: [Internal] Internal change

Reviewed By: JoshuaGross

Differential Revision: D21137348

fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db

* Add support for generating custom messages

Summary:
Until now we've generated scaffolding entirely based on the official devtools
protocol spec. This diff adds support for defining custom domains in `custom.json`
which will be merged with the upstream protocol JSON definition.

ChangeLog: [Internal] Add support for Hermes-specific CDP messages

Reviewed By: bestander

Differential Revision: D20754605

fbshipit-source-id: a8075f81816a40114d1a3332192c7aa076b17848

* Implement Hermes.setPauseOnLoad

Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.

The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.

Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call

Reviewed By: bestander

Differential Revision: D20754604

fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909

* Switch isPackagerRunning to a class method.

Summary:
This diff exports `isPackagerRunning` as a class method to be used without and instance.

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21094414

fbshipit-source-id: 44becb59e3c08d66e4992c4c1b32d6efcd4fe257

* Fabric: Fixed `getDirtied` vs `isDirty` in `YogaLayoutableShadowNode`

Summary:
This is quite a fateful mistake. `getDirtied()` returns the pointer to a function which is obviously a mistake here; we should use `isDirty()` instead.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028569

fbshipit-source-id: 95212b31f4e32d51c594d5209f295397af3f1252

* Fabric: More strict policies to dirty Yoga nodes in YogaLayoutableShadowNode

Summary:
Yoga uses a dirty flag to re-layout nodes. In normal, single-threaded approach the policy for dirtying is simple: if a node was changed, we need to dirty it. In the Concurrent Yoga approach, those rules are not so simple, and it seems we haven't formalized those rules yet.

Investigating some layout issues that we have in Fabric, I tend to believe that we don't dirty as much we should. Hense this change adds mode dirtying.

Reviewed By: JoshuaGross

Differential Revision: D21092815

fbshipit-source-id: 4603c97ccb79efcdf5e6a4cc450ebe61b63effb3

* Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors (#28703)

Summary:
Per discussion in https://github.com/react-native-community/releases/issues/186 the iOS `PlatformColor()` function is documented to use the semantic color names provided by the system.   The referenced HIG documentation itself links to the `UIColor` documentation for semantic colors names.   However, these names differ depending on if you are viewing the new Swift API docs or the Objective C docs.   The current Objective C implementation in react-native assumes Objective C UIColor selector names that are suffixed 'Color'.   But in Swift, Apple provides a Swift Extension on UIColor that makes aliases without the the 'Color' suffix and then makes the original selectors invalid presumably via `NS_UNAVAILABLE_SWIFT`.

Since both selector names are valid depending on if you are using Objective C or Swift, let's make both forms be legal for `PlatformColor()`.   In `RCTConvert.m` there is a dictionary of legal selector names.   The code already supports the ability to have names be aliases of other selectors via a RCTSelector metadata key.   The change adds code to the initialization of the map: it iterates over the keys in the map, which are all ObjC style UIColor selectors, and creates aliases by duplicating the entries, creating key names by stripping off the ObjC "Color" suffix, adds the RCTSelector key referring to the original and then appends these new Swift aliases to the map.

## Changelog

[iOS] [Changed] - Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors
Pull Request resolved: https://github.com/facebook/react-native/pull/28703

Test Plan:
The PlatformColorExample.js is updated to use the new, shorter Swift selector names.   There are still other examples in the same file and in unit tests that exercise the ObjC selector names.

<img width="492" alt="PlatformColor" src="https://user-images.githubusercontent.com/30053638/79809089-89ab7d00-8324-11ea-8a9d-120b92edeedf.png">

Reviewed By: shergin

Differential Revision: D21147404

Pulled By: TheSavior

fbshipit-source-id: 0273ec855e426b3a7ba97a87645859e05bcd4126

* Update Differ test

Summary:
Update differ test so it passes again. Previously to D21111423 (I think) nodes were being incorrectly detected as updated even if they weren't different, so now there are fewer unnecessary Update mutations generated.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21148647

fbshipit-source-id: cab6e3ecd0a457e1ac3155b3468bcc56663dab0b

* Enable Yoga logging in Fabric Debug

Summary:
This diff extends Fabric to support Yoga logging

changeLog: [Internal] Internal changes in Fabric to enable yoga logging

Reviewed By: JoshuaGross

Differential Revision: D21150195

fbshipit-source-id: a2e8308a79a7b422bf9ecc3a65f822b305f02c5d

* Easy diff to document in code how to enable logging of Shadow Tree instrospection

Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection

changeLog: [Internal] Internal change used on Fabric

Reviewed By: JoshuaGross

Differential Revision: D21150196

fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd

* Flip text alignment in case layout direction is RTL

Summary:
Changelog: [Internal]

Flip text alignment in case layout direction is RTL.

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21130371

fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b

* Daily `arc lint --take GOOGLEJAVAFORMAT`

Reviewed By: zertosh

Differential Revision: D21154707

fbshipit-source-id: 11956915c265f98e286638b91d66d51545e3a311

* Upgrade Flipper to 0.37.0 (#28545)

Summary:
Bump flipper to 0.37 for both iOS and Android

## Changelog

[Android] [Changed] - Upgrade Flipper to 0.37.0
[iOS] [Changed] - Upgrade Flipper to 0.37.0
Pull Request resolved: https://github.com/facebook/react-native/pull/28545

Test Plan: RNTester build pass

Reviewed By: rickhanlonii

Differential Revision: D20930069

Pulled By: hramos

fbshipit-source-id: a7cb719da3e51e6a42d27d5e64bc664398d0d3c5

* Upgrade babel-eslint in xplat/js

Summary:
`babel-eslint` is the parser you can supply to ESLint based off of Babel.

`babel-eslint` 10.1.0 is the newest production version of `babel-eslint`.

There are very few changes between 10.0.1 (the lowest previous version) and 10.1.0. There are only 3 non-version-bump commits: 2 bug fixes and enabling parsing of Flow enums.

The only project that was on a lower version than 10.0.1 was `/xplat/js/RKJSModules/Libraries/Relay/oss/__github__` - test below

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21055850

fbshipit-source-id: bae0d8af5c6d833a4dbb0ad775c8e5e78ead1051

* RN: Create `RootTag` Type

Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.

This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21127173

fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0

* RN: Add `RootTag` Type to TurboModule

Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).

This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:

- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: RSNara

Differential Revision: D21127170

fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb

* RN: Fix Codegen Schema Buck Dependency (#28719)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719

The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21162993

fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658

* Flow 0.123.0 in xplat/js

Summary:
Changelog: [Internal]

## Sync of generated files

Ran
```
js1 upgrade www-shared -p core_windowless
```
but had to manually revert
```
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLoggerType.flow.js
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLogger.js
```
because they introduced more errors

## Flow version bump
```
~/fbsource/fbcode/flow/facebook/deploy_xplat.sh 0.123.0
```

Reviewed By: gkz

Differential Revision: D21159821

fbshipit-source-id: e106fcb43e4fc525b9185f8fc8a246e6c3a6b14f

* Remove outdated metro type definitions

Summary:
RN itself does not depend on Metro any longer, which is abstracted away into the CLI. I don't think we need those type definitions any longer as we have proper Metro definitions internally. I'm removing them because they keep showing up in biggrep when I look for things.

Changelog: [Internal]

Reviewed By: GijsWeterings

Differential Revision: D21089924

fbshipit-source-id: 2845277af12dae0f0baefaf85adefffb6ef9f2a5

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D21175893

fbshipit-source-id: 101734c1b968ce241a15648efdcaeabbd789952d

* remove tvOS from template (#28706)

Summary:
According to the [0.62 blog post](https://reactnative.dev/blog/2020/03/26/version-0.62), Apple TV support has moved to react-native-tvos.
The template still contains info.plist for tvOS, so I've removed them for future releases.

## 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] [Removed] - Removed tvOS related files from the template
Pull Request resolved: https://github.com/facebook/react-native/pull/28706

Test Plan: run `react-native init TestTemplate` and remove tvOS related files and verified that iOS and Android runs on emulator.

Differential Revision: D21182211

Pulled By: hramos

fbshipit-source-id: 41d2e19e5158d7ec103a37c01a93cf511fc1e4c9

* Fabric: `ConcreteShadowNode::initialStateData()` now accepts a `ShadowNodeFamilyFragment` instead of just a `SurfaceId`

Summary:
We need it to be able pass an `EventEmitter` object to constructed concrete State objects.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21169581

fbshipit-source-id: 3eef0310de7e2f061108aa85c1a39678a43fe85e

* Fabric: Introducting `ShadowNodeFamilyFragment::Value`

Summary:
`ShadowNodeFamilyFragment::Value` is a value couter-part type for `ShadowNodeFamilyFragment`.
We need that to be able safely copy data stored inside a `ShadowNodeFamilyFragment` object.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: kacieb

Differential Revision: D21169580

fbshipit-source-id: 1a485e1b2ae47bc7da9476a60466934ac9d61366

* Overhaul RCTTurboModule creation and initialization

Summary:
## Problems:
In my investigation of T65656635, I realized that the TurboModule system has a number of problems:
- In TurboModules, we use 1 lock to create n TurboModules. We should change this setup to n locks for n TurboModules. This way, two threads creating two different NativeModules don't compete for the same lock. Also, this is how it's done in Android (TurboModules & NativeModules), and iOS (NativeModules).
- In TurboModules, we don't calculate "requires main queue setup" faithfully. In the legacy system, if a NativeModule has a custom `init` method or a custom `constantsToExport` method, it "requires main queue setup" with a warning.
- In TurboModules, we don't create the NativeModule on the main queue, if "requires main queue setup" is true. Instead, the NativeModule is always created on the thread that requires it.
- In TurboModules, we don't perform any concurrency control around `id<RCTTurboModule>` setup. We should.

## What this diff does
In this diff, I fixed all the aforementioned issues by re-implementing `provideRCTTurboModule:`.

**Algorithm Notes:**
- **Gist:** When `n` threads race to create NativeModule `x`, only the first thread creates and sets up `x`. All others are told to wait. Once the creator thread finishes its job, it notifies all other waiting threads, which then wake up and return the newly created NativeModule. This algorithm was initially implemented in NativeModules for Android inside (ModuleHolder.java). I modified and implemented it for TurboModules for Android, and now this diff implements it for TurboModules for iOS.
- The TurboModule cache is replace with a TurboModuleHolder map. A TurboModuleHolder manages the creation lifecycle of a TurboModule, and holds a condition variable and mutex for doing concurrency control around it. When the bridge invalidates, in TurboModuleManager, we set the `invalidating` flag to true, which prevents the insertion of new entries into the TurboModuleHolder map.
- I added a `std::mutex` to serialize calls into the TurboModuleManagerDelegate, so we don't get races if the delegate isn't thread-safe.

Changelog:
[iOS][Fixed] - Re-implement RCTTurboModuleManager provideRCTTurboModule:

Reviewed By: shergin

Differential Revision: D21170099

fbshipit-source-id: 8792812c2237d3bfc80c9834c818e011de85b0ea

* Fix folly::dynamic crash when attaching a debugger to Hermes

Summary:
folly_futures was compiled with and exported -DFOLLY_MOBILE=1, while
folly_json did not. This flag disables fancy F14 data structures for
folly::dynamic in favor of a simple std::unordered_map.

This caused inlined/templated code from modules depending on
folly_futures to disagree with the implementations in folly_json,
leading to a crash.

The only such libraries were libhermes-inspector and (transitively)
libhermes-executor-debug, and these only use folly::dynamic for CDP
serialization, which is why the problem was not more apparent.

Changelog: [Internal] Fix crash when attaching a Hermes debugger

Reviewed By: mhorowitz

Differential Revision: D21193307

fbshipit-source-id: 2b795bb6f4f7f991e2adaacec62d62616117322b

* Set black as default text color for <TextInput/> on iOS (#28708)

Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested …
amgleitman added a commit to microsoft/react-native-macos that referenced this issue Aug 4, 2021
* Update default Podfile to not depend on a path (#28572)

Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.

While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.

https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9

Unfortunately, due to the way Ruby works, this completely hides the path away from the users.

Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.

With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.

https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10

This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.

As a result, we don't have to change the paths here whether we're running monorepo or not.

## Changelog

[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: https://github.com/facebook/react-native/pull/28572

Differential Revision: D20945194

Pulled By: TheSavior

fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27

* Upgrade Prettier in Xplat to version 1.19.1

Summary:
Upgrades Prettier in Xplat to 1.19.1
Ignores upgrading packages on already on versions greater than 1.19.1

Changelog: [Internal]

allow-large-files
bypass-lint

(Note: this ignores all push blocking failures!)

Reviewed By: gkz, cpojer

Differential Revision: D20879147

fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d

* Stop using get_fbobjc_enable_exception_lang_compiler_flags_DEPRECATED in xplat

Summary:
Old deprecated function.

Changelog: [Internal]

Reviewed By: nlutsenko

Differential Revision: D20148856

fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469

* Add ProGuard rule for hermes (#28571)

Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
https://github.com/facebook/react-native/issues/28270

## 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] - ProGuard rule for hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d

* Move CheckBox JS files to FB Internal

Summary:
Move CheckBox JS files to FB internal

## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D20910775

fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327

* fix: ripple should be applied even when borderless == false (#28526)

Summary:
With current master, when you render `<Pressable android_ripple={{borderless: false}}>`, there is no ripple effect at all.

I think the expected behavior is to have ripple with default color and radius, just not borderless.

This was how it was done (by me) in https://github.com/facebook/react-native/pull/28156/files but in the import process, the implementation was changed: https://github.com/facebook/react-native/commit/bd3868643d29e93610e19312571a9736df2cbdf8 so either this PR is a fix or you can just close it (but I'd be curious why).

## 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] [fixed] - ripple should be applied even when borderless == false
Pull Request resolved: https://github.com/facebook/react-native/pull/28526

Test Plan:
`<Pressable android_ripple={{borderless: false}}>` on master

![SVID_20200404_123614_1](https://user-images.githubusercontent.com/1566403/78424971-6b315a80-7671-11ea-8be4-5fea428bc556.gif)

`<Pressable android_ripple={{borderless: false}}>` in this PR

![SVID_20200404_122754_1](https://user-images.githubusercontent.com/1566403/78424986-8bf9b000-7671-11ea-9804-37cd58dbb61e.gif)

Differential Revision: D20952026

Pulled By: TheSavior

fbshipit-source-id: df2b95fc6f20d7e958e91805b1a928c4f85904f1

* Remove ColorAndroid function as it adds no value over PlatfromColor (#28577)

Summary:
This change removes the `ColorAndroid` API.   It was added more as a validation tool than as something useful to a developer.   When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc.    Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`.    Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.

## 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] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577

Test Plan: RNTester in both iOS and Android was tested.   Jest tests, Flow checks, Lint checks all pass.

Reviewed By: cpojer

Differential Revision: D20952613

Pulled By: TheSavior

fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0

* iOS: mark some old NativeModule targets with depslint_never_remove

Summary:
Label some BUCK targets properly.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D20960917

fbshipit-source-id: 42fa2266105b6c3dd5108a1b56035a19a95cd61f

* Update Gradle Wrapper to 6.3 (#28173)

Summary:
```
Welcome to Gradle 6.3!

Here are the highlights of this release:
 - Java 14 support
 - Improved error messages for unexpected failures

For more details see https://docs.gradle.org/6.3/release-notes.html
```

## Changelog

[Android] [Changed] - Update Gradle Wrapper to 6.3
Pull Request resolved: https://github.com/facebook/react-native/pull/28173

Test Plan: Build project

Differential Revision: D20958894

Pulled By: mdvacca

fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f

* Fix crash inside RCTRedBox when trying to present same UIViewController twice

Summary:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash

We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:

> A Boolean value indicating whether the view controller is being presented.

Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#

 ---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.

```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```

Changelog: Fix crash caused by presenting view controller twice from RCTRedBox

Reviewed By: PeteTheHeat

Differential Revision: D20946645

fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81

* Animated: Early detection of division by zero in AnimatedDivision

Summary:
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] Early crash in AnimatedDivision in case of division by zero.

Reviewed By: mdvacca

Differential Revision: D20969087

fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344

* Fabric: Controlling DifferentiatorMode via ReactNativeConfig

Summary:
Now we can control the differentiator mode via MC.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: fkgozali

Differential Revision: D20978857

fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4

* Upgrade Hermes dependency to 0.5.0

Summary:
Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`.

Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0

allow-large-files

Reviewed By: mhorowitz

Differential Revision: D20998564

fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50

* Set width/height also to Undefined when we change the measure mode to Undefined

Summary:
Make sure width/height is always passed as Undefined when measure mode is changed to Undefined.

Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined

Reviewed By: alickbass

Differential Revision: D20029838

fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304

* Remove redundant input from TextInput

Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D21016502

fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088

* Update RNTester AppDelegate for changes made to SurfacePresenter API (#28580)

Summary:
This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`.

## Changelog

[Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/28580

Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled.

Reviewed By: hramos

Differential Revision: D20966067

Pulled By: mdvacca

fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1

* Retryable ViewCommand exceptions shouldn't crash

Summary:
Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing).

Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow.

If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely.

The only concern I have with landing this is the perf implications of putting a try/catch inside this loop.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21023213

fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82

* Remove setMostRecentEventCount from TextInput view commands

Summary:
Changelog: [Internal]

We don't use view command `setMostRecentEventCount`, let's get rid of it.

Reviewed By: JoshuaGross

Differential Revision: D21016600

fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b

* label-actions: Add canned response for upgrade issues

Summary:
Enhance the label-actions config and support a "Type: Upgrade Issue" label.
- Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied.
- Close the issue.

Changelog:
[Internal] label-actions: Add canned response for upgrade issues

Reviewed By: cpojer

Differential Revision: D20974607

fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56

* Yoga Podspec: Export YGNode and YGStyle headers (#997)

Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.

The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.

This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.

I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.

Changelog:

[Internal] - Yoga Podspec: Export YGNore and YGStyle headers

Pull Request resolved: https://github.com/facebook/yoga/pull/997

Reviewed By: hramos

Differential Revision: D20966075

Pulled By: mdvacca

fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e

* Add logging to catch null TurboModules

Summary:
We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027984

fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6

* Remove module cache from ReactPackageTurboModuleManagerDelegate

Summary:
This cache is unnecessary, because:
1. TurboModuleManager caches all created TurboModules
2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`.

This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027998

fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7

* Control concurrent calls into TMMDelegate from TMM

Summary:
In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created.

## The problem:
What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees.

## The fix
`TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood).

Changelog:
[Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager

Reviewed By: mdvacca

Differential Revision: D21025965

fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df

* Bump eslint-plugin-react-native-community version to 1.1.0

Summary:
This release will include the new platform-colors rule.

Changelog: [Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21022163

fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7

* Update Babel to 7.8.x/7.9.x

Reviewed By: motiz88

Differential Revision: D20697095

fbshipit-source-id: ef35d02da0916109ce528d3026f7ca0956911dda

* fix: do not throw on missing `cliPath`, use the default value (#28625)

Summary:
The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file.

In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change.

## Changelog

[ANDROID] [INTERNAL] - Don't require `cliPath`
Pull Request resolved: https://github.com/facebook/react-native/pull/28625

Test Plan:
Run Android project, everything works.
Provide custom `cliPath`, it gets respected

Reviewed By: cpojer

Differential Revision: D21044222

Pulled By: TheSavior

fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e

* Fix CIRCLE_PR_NUMBER may not always be set (#28640)

Summary:
This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork.

## Changelog

[Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set
Pull Request resolved: https://github.com/facebook/react-native/pull/28640

Test Plan: Report bundle size step should pass on both this PR and https://github.com/facebook/react-native/issues/28641.

Reviewed By: cpojer

Differential Revision: D21045553

Pulled By: TheSavior

fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608

* Add "Open Debugger" and "Open React DevTools" to iOS dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D20784270

fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd

* Changed iOS LaunchScreen from xib to storyboard (#28239)

Summary:
> Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens.

Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b).

Community discussion: https://github.com/react-native-community/discussions-and-proposals/issues/209

## Changelog

Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required.

[iOS] [Deleted] - Deleted LaunchScreen.xib
[iOS] [Added] - Added LaunchScreen.storyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/28239

Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one.

Reviewed By: cpojer

Differential Revision: D20408892

Pulled By: hramos

fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a

* Switch over to JavaTurboModule::InitParams

Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).

**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.

## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
 public:
  struct InitParams {
    std::string moduleName;
    jni::alias_ref<JTurboModule> instance;
    std::shared_ptr<CallInvoker> jsInvoker;
    std::shared_ptr<CallInvoker> nativeInvoker;
  };
```

All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments.  Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.

## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.

## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.

## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.

## Commands run

Reviewed By: fkgozali

Differential Revision: D21035208

fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c

* RN: Shrinkwrap Text Layout (Android)

Summary:
When text is in a constrained parent view using `maxWidth`, long text may wrap. When the text wraps, the final width is dependent on the word breaking strategy and text content. This means that the text width is not necessarily `maxWidth`.

However, the current way that we compute text layout does not shrinkwrap the text width as much as possible. This leads to visual gaps to the end-side of wrapped text.

This changes the text layout slightly so that we use the length of the longest line.

This bug only exists on Android. After this change, Android behaves like iOS.

Changelog:
[Android] [Fixed] - Fixed excessive space in Text view with word-wrapping

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21056031

fbshipit-source-id: e9b7793f2632caafcce69bc15bac61330b0ed958

* (eslint-config) update community eslint plugin in eslint config (#28642)

Summary:
Updating the community eslint-plugin used in the eslint-config to the latest version.

expecting new eslint-config version to be released with this change so that it can be included in new project template for 0.63 https://github.com/react-native-community/releases/issues/186

## 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 community eslint plugin in the eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/28642

Test Plan: yarn lint passes

Differential Revision: D21048976

Pulled By: cpojer

fbshipit-source-id: 2c3ec0ef450cf357d8c88db7873f4ca1154b2034

* chore: update CLI to the latest version (#28623)

Summary:
Bumps CLI to the latest version, needed by https://github.com/facebook/react-native/pull/28572 to work.

## Changelog

[INTERNAL] - Bump CLI to latest
Pull Request resolved: https://github.com/facebook/react-native/pull/28623

Reviewed By: hramos

Differential Revision: D21017766

Pulled By: cpojer

fbshipit-source-id: 62a873923c58f8752edb0394db7e6dfceed92485

* Add "Open Debugger" and "Open React DevTools" to Android dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20784279

fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb

* Remove the post install step (#28651)

Summary:
Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5.

cc alloy

## 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
-->

[Flipper] [Template] - Remove the post install step for Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/28651

Test Plan: Tested a newly created RN app without post install step and it built successfully.

Reviewed By: passy

Differential Revision: D21064653

Pulled By: priteshrnandgaonkar

fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac

* Revert D21064653: Remove the post install step

Differential Revision:
D21064653

Original commit changeset: da56d0754d91

fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124

* Remove out of date TODO

Summary:
No longer relevant.

Changelog: [Internal]

Reviewed By: mhorowitz

Differential Revision: D21070955

fbshipit-source-id: 11b0384501b2780f5ac41899b5e8bbb4f7a4d730

* RNTester LayoutAnimation example: add more options

Summary:
Add more options to the LayoutAnimation example so it's easier to test more features of LayoutAnimations.

1) Add an option to animate reordering of views
2) Make animations slower, so it's easier to see what's going on and easier to trigger race conditions
3) Add options to mutate without animation, to test interrupting existing animations

Changelog: [Internal] Updated Catalyst RNTester LayoutAnimation example with additional options

Reviewed By: mdvacca

Differential Revision: D21050309

fbshipit-source-id: 1daba4fd487693c34a2d40eb39a68c7d03c24f93

* Add a "reparenting" LayoutAnimation example that animates flattening/unflattening

Summary:
Simple test to see what it looks like when view flattening/unflattening is animated with LayoutAnimations.

Changelog: [Internal] adding another example to LayoutAnimations example

Reviewed By: mdvacca

Differential Revision: D21074805

fbshipit-source-id: 551ed740f0ab5c5adcb19f5c35e932b8983cd108

* Fix jsi cmake include dirs (#207)

Summary:
I'm trying to use JSI for a React Native custom module. I saw these existing examples where the JSI API is used in the context of a CMakeLists.txt:
https://github.com/terrysahaidak/host-object-test/blob/master/libs/android-jsi/test-jsi/src/main/cpp/CMakeLists.txt
https://github.com/ericlewis/react-native-hostobject-demo/pull/4/files#diff-834320be1b4e4016bac27c05dcd17fb9
In both cases, they manually grab the include directories and jsi.cpp from node_modules/react-native, but I also saw that node_modules/react-native/ReactCommon/jsi/jsi already has a CMakeLists.txt that appears to be intended to provide a jsi static lib, so I tried to pull this into my own CMakeLists.txt like this:
```
add_subdirectory(${RN_DIR}/ReactCommon/jsi/jsi ${CMAKE_CURRENT_BINARY_DIR}/jsi)
...
target_link_libraries(MyLib jsi)
```
Unfortunately when doing this, the consuming project still doesn't see the correct include directories. The change I'm proposing here is to use `target_include_directories` and declare that `..` is a public (to consumers) include directory for the library named `jsi`. With this change, you can do what I showed above to consume the jsi lib by just pulling in the CMakeLists.txt file into your own CMakeLists.txt file.

Changelog: [General][Fixed] Fix jsi cmake include dirs

Pull Request resolved: https://github.com/facebook/hermes/pull/207

Reviewed By: willholen

Differential Revision: D21074270

Pulled By: tmikov

fbshipit-source-id: 7d9ec3255f57a16c0b2be489dffa4540727738a1

* Resolve `kind-of` vulnerability by bumping to 6.0.3

Summary:
https://github.com/advisories/GHSA-6c8f-qphg-qjgp

Changelog:
[General][Changed] Updated transitive dependency kind-of to 6.0.3 to resolve vulnerability

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21077747

fbshipit-source-id: d5c19b21b665130c6423f5caeddcd6378bac7dcb

* Move CheckBox Android files to FB internal (#28658)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28658

This moves the Java files to FB internal and updates all the buck files.

## Changelog:

[Android] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D21066998

fbshipit-source-id: 76821fcae899ff7342697ea7dd4737ef3b008213

* Part 1: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.

## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.

## Commands run
```
function update-codegen() {
  pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}

> update-codegen
```

Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036266

fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086

* Part 2: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035209.

## Changes
- Codemod all ObjC NativeModule `getTurboModuleWithJsInvoker:nativeInvoker:perfLogger` methods to `getTurboModule:(const ObjCTurboModule::Args)`

## Script
```
var withSpaces = (...args) => args.join('\s*')

var regexString = withSpaces(
  '-',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<turboModuleClass>(facebook::react::|react::|::|)TurboModule)',
  '>',
  '\)',
  'getTurboModuleWithJsInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<fbNamespace>(facebook::react::|react::|::|))CallInvoker',
  '>',
  '\)',
  '(?<jsInvokerInstance>[A-Za-z0-9]+)',
  'nativeInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(facebook::react::|react::|::|)CallInvoker',
  '>',
  '\)',
  '(?<nativeInvokerInstance>[A-Za-z0-9]+)',
  'perfLogger',
  ':',
  '\(',
  'id',
  '<',
  'RCTTurboModulePerformanceLogger',
  '>',
  '\)',
  '(?<perfLoggerInstance>[A-Za-z0-9]+)',
  '{',
  'return',
  'std::make_shared',
  '<',
  '(?<specName>(facebook::react::|react::|::|)Native[%A-Za-z0-9]+SpecJSI)',
  '>',
  '\(',
  'self',
  ',',
  '\k<jsInvokerInstance>',
  ',',
  '\k<nativeInvokerInstance>',
  ',',
  '\k<perfLoggerInstance>',
  '\)',
  ';',
  '}',
)

var replaceString = `- (std::shared_ptr<$<turboModuleClass>>) getTurboModule:(const $<fbNamespace>ObjCTurboModule::InitParams &)params
{
  return std::make_shared<$<specName>>(params);
}`

const exec = require('../lib/exec');
const abspath = require('../lib/abspath');
const relpath = require('../lib/relpath');
const readFile = (filename) => require('fs').readFileSync(filename, 'utf8');
const writeFile = (filename, content) => require('fs').writeFileSync(filename, content);

function main() {
  const tmFiles = exec('cd ~/fbsource && xbgs -n 10000 -l getTurboModuleWithJsInvoker:').split('\n').filter(Boolean);

  tmFiles
    .filter((filename) => !filename.includes('microsoft-fork-of-react-native'))
    .map(abspath)
    .forEach((filename) => {
      const source = readFile(filename);
      const newSource = source.replace(new RegExp(regexString, 'g'), replaceString);

      if (source == newSource) {
        console.log(relpath(filename));
      }

      writeFile(filename, newSource);
    });
}

if (!module.parent) {
  main();
}
```

## Re-generating diff
```
> hg revert -r .^ --all
> node index.js # run script
```

Changelog: [iOS][Changed] - Make all ObjC NativeModules create TurboModules using ObjCTurboModule::Args

Reviewed By: PeteTheHeat

Differential Revision: D21036265

fbshipit-source-id: 404bcc548d1775ef23d793527606d02fe384a0a2

* Part 3: Update RCTTurboModuleManagerDelegate to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- Update `RCTTurboModuleManagerDelegate getTurboModule:instance:jsInvoker:nativeInvoker:perfLogger` to use `RCTTurboModuleManagerDelegate getTurboModule:(const ObjCTurboModule::InitParams)`
- Update all implementations of `RCTTurboModuleManagerDelegate` in accordance with this API change

Changelog:
[iOS][Changed] - Make RCTTurboModuleManagerDelegate create TurboModules via ObjCTurboModuleManager::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036272

fbshipit-source-id: c16002c47db26e2ba143fc1080afe9e2fe1e7816

* chore: update `./scripts/test-manual-e2e.sh` (#28653)

Summary:
Recent changes broke the script - wrong path to open `RNTesterPods.xcworkspace` and other scripts - we change dir with `cd`.

Another change is incorrect use of `RNTesterProject.xcodeproj` instead of a `xcworkspace`.

This PR is a simple and short fix to make it run.

## Changelog

[INTERNAL] - chore: update `./scripts/test-manual-e2e.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/28653

Test Plan: Run `./scripts/test-manual-e2e.sh`. Things work.

Differential Revision: D21079792

Pulled By: hramos

fbshipit-source-id: 6bdb8be016f044852ed216ec53f80db40c84b5fd

* use default value of enums YGDirection and YGMeasureMode instead of -1

Summary:
Changelog:
[Internal][Yoga] YGDirection variable was initialized incorrectly by casting -1 to YGDirection. Changing it to default value of direction

Same for YGMeasureMode.

Reviewed By: pasqualeanatriello

Differential Revision: D20869042

fbshipit-source-id: 7bfe490193321baae875ef6fb49a938851950c9f

* fix typo as there is no file called YGJNI.cpp (#990)

Summary:
fix typo in `YogaJNIBase.java` as there is no such file called `YGJNI.cpp`
Pull Request resolved: https://github.com/facebook/yoga/pull/990

Reviewed By: pasqualeanatriello

Differential Revision: D20735102

Pulled By: SidharthGuglani

fbshipit-source-id: 3f9f4d78ba390feae3451330f997a221ab4ec70e

* Remove unused packages from xplat/js/package.json

Summary:
We have a large amount of small packages that are completely unused, or only have one call site. This diff cleans up a lot of them and reduces node_modules by 12 MiB (down to 187).

Changelog: [Internal]

Reviewed By: motiz88

Differential Revision: D21088213

fbshipit-source-id: 5fa7d3da5cbe744b0d9d3e3450d6135c1488ee79

* Make ColorValue public in StyleSheet.js

Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.

Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet

Reviewed By: TheSavior

Differential Revision: D21076969

fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab

* Fabric: `LayoutableShadowNode:getLayoutMetrics` is not a virtual method anymore

Summary:
We don't use it as vitrual anymore (setLayoutMetrics is a non-virtual method already), so it does not need to be marker virtual.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028572

fbshipit-source-id: 99f86fdd4cf2f5972034d9058d7b82bdc8680187

* Fabric: Proper traits for `ImageShadowNode` and `ViewShadowNode`

Summary:
* <Image> must be a leaf node; having a proper trait will fail earlier in case of misuse (mounting something inside).
* <View> must have a `View` trait because it's for what that trait is.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D21028573

fbshipit-source-id: 457716d4661333eb2357f34316f3e495ab4fda24

* Fabric: "Attempt to mutate a sealed object." is now an assert (not exception)

Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028571

fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9

* Fabric: Implementation of `getDebugDescription` for `std::array`

Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028570

fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd

* Fabric: `componentregistry` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885163

fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af

* Fabric: `scheduler` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885645

fbshipit-source-id: 8148bd934879802b076261ed86fa78acf0a07ed3

* Fabric: `templateprocessor` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885646

fbshipit-source-id: b8e3199c0eacc57a5be1481595cf97c84f972293

* Migrate deprecated frameInterval to preferredFramesPerSecond (#28675)

Summary:
[frameInterval](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval) was deprecated in favor of [preferredFramesPerSecond](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1648421-preferredframespersecond).

This migrates the deprecated call over.

## 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
-->

[iOS] [Fixed] - Migrate frameInterval to preferredFramesPerSecond
Pull Request resolved: https://github.com/facebook/react-native/pull/28675

Test Plan: Xcode should no longer throw warnings about the deprecated call.

Differential Revision: D21109710

Pulled By: shergin

fbshipit-source-id: 772b9f625d3e22cd4d8cd60bddad57ff8611af54

* Fabric: Fix case of Glog include in MountingTest.cpp (#28616)

Summary:
This pull request changes the include of Glog from `<Glog/logging.h>` to `<glog/logging.h>` in `MountingTest.cpp`. This fixes building on a case-sensitive filesystem.

## Changelog

[Internal] [Fixed] - Fabric: Fix case of Glog include in MountingTest.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/28616

Test Plan: The `include` of Glog no longer causes issues with building `MountingTest.cpp` on a case-sensitive filesystem.

Differential Revision: D21118085

Pulled By: shergin

fbshipit-source-id: c958c54bf88333fd5001127779c855ce8c2666c3

* Fabric: Add Unicode prefix to AttachmentCharacter (#28617)

Summary:
This pull request adds a Unicode `u8` prefix to the string literal returned in `AttributedString.cpp`'s `Fragment::AttachmentCharacter()`.

This fixes the following error when building on MSVC:

```
react\attributedstring\AttributedString.cpp(21): error C4566: character represented by universal-character-name '\uFFFC' cannot be represented in the current code page (1252)
```

## Changelog

[Internal] [Fixed] - Fabric: Add Unicode prefix to AttachmentCharacter
Pull Request resolved: https://github.com/facebook/react-native/pull/28617

Test Plan: The Fabric test suite has been ran on a Clang-based build of Fabric on macOS, and no regressions in it have been noted.

Differential Revision: D21118078

Pulled By: shergin

fbshipit-source-id: c105de5e4edb67fed97ce44153a75d9d380bf588

* Fabric: Fixed incorrect early-return in `UIView+ComponentViewProtocol::updateLayoutMetrics`

Summary:
Before the change, an incorrect (NaN or Inf) values in LayoutMetrics might force an early return in the `updateLayoutMetrics:oldMetrics:` method implementation. This was not correct because the rest of the method also didn't run in this case, so it might force some value to stale.
E.g., imagine we have an instruction that contains NaN size and `display: none`. Previously, the function might just return right before applying sizes and progress the stored "already applied" value of LayoutMetrics which will cause the view being visible even if it should not.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110644

fbshipit-source-id: 501319d7b1dcd5c18f27e0ceca3c8d207485c49b

* Fix border-stroke drawing after resetting border-radius (#28356)

Summary:
This PR fixes incorrect drawing of the View borders on Android, after changing the border-radius back to 0 *(and when no background-color is defined)*.

This happens because the `drawRoundedBackgroundWithBorders` function in ReactViewBackgroundDrawable changes the style on the Paint object to `STROKE`. This style is however never reverted back to `FILL`. This change ensures that the Paint style is set to `FILL` for the full execution of the `drawRectangularBackgroundWithBorders` function.

## Changelog

`[Android] [Fixed] - Fix border-drawing when changing border-radius back to 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28356

Test Plan:
**Faulty situation:**

![ezgif com-video-to-gif](https://user-images.githubusercontent.com/6184593/77153163-9759b280-6a99-11ea-82bb-33a1e0a4934c.gif)

**After the fix:**

![ezgif com-video-to-gif (1)](https://user-images.githubusercontent.com/6184593/77153825-c91f4900-6a9a-11ea-8e0c-a4280b9e72b8.gif)

Differential Revision: D21124741

Pulled By: shergin

fbshipit-source-id: 2044f8e8ad59a58df42b64d7ee8c4ad1d3b562f1

* Fabric: Using proper clock in MountingTelemetryTest

Summary:
Apparently, `std::this_thread::sleep_for` uses a different clock to measure time which causes ofter misalignment with the clock which Telemery uses which makes the test flaky. Using the same clock should fix it.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21116058

fbshipit-source-id: 52dde2e325776d365431a2a957dcc12dfe53f890

* Fix rounded border drawing when border-radius is smaller than border-width (#28358)

Summary:
This PR fixes the drawing of the border rounded edges when the border-radius is small than the border-width. The current implementation capped the possible border-radius making it impossible to set smaller border-radii when using thicker borders. After inspection it was found that the rounded-rect calculation is incorrect.

## Changelog

`[Android] [Fixed] - Fix rounded border-drawing when border-radius is smaller than border-width`
Pull Request resolved: https://github.com/facebook/react-native/pull/28358

Test Plan:
**Faulty situation:**

As you can see, when the border-radius becomes very low, the border is stuck at a minimum value. Only after setting the border-radius fully to 0 is it again rendered correctly.

![ezgif com-video-to-gif (2)](https://user-images.githubusercontent.com/6184593/77183540-c3435b00-6ace-11ea-950d-29a0ea1757bd.gif)

**After the fix:**

![ezgif com-video-to-gif (3)](https://user-images.githubusercontent.com/6184593/77183619-e837ce00-6ace-11ea-93a5-910127d352b7.gif)

Differential Revision: D21124739

Pulled By: shergin

fbshipit-source-id: cefd1776b77b5b9fb335e95fd7fdd7f345579dc4

* Fabric: `ComponentDescriptor::cloneProps()` now never returns the base props objects

Summary:
The diff changes how the `empty raw props` optimization works in `ComponentDescriptor::cloneProps()`. Now it only fires only when the base `props` object is null, which is practically all production cases we have (and care about). (I tried, in a normal run there were no cases where the empty raw props were passed with non-null props.) From the other side, the old behavior that may return the same props objects previously several times created bugs and practically unexpected results and practically disallowed to clone props objects easily.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110608

fbshipit-source-id: 884807cd8e9c5c3e6cc1c9e4c1f0227259cc21fb

* Upgrade to Jest 25

Summary:
This diff upgrades Jest to the latest version which fixes a bunch of issues with snapshots (therefore allowing me to enable the Pressable-test again). Note that this also affects Metro and various other tooling as they all depend on packages like `jest-worker`, `jest-haste-map` etc.

Breaking changes: https://github.com/facebook/jest/blob/master/CHANGELOG.md

This diff increases node_modules by 3 MiB, primarily because it causes more duplicates of `source-map` (0.8 MiB for each copy) and packages like `chalk` 3.x (vs 2.x). The base install was 15 MiB bigger and I reduced it to this size by playing around with various manual yarn.lock optimizations. However, D21085929 reduces node_modules by 11 MiB and the Babel upgrade reduced node_modules by 13 MiB. I will subsequently work on reducing the size through other packages as well and I'm working with the Jest folks to get rid of superfluous TypeScript stuff for Jest 26.

Other changes in this diff:
* Fixed Pressable-test
* Blackhole node-notifier: It's large and we don't need it, and also the license may be problematic, see: https://github.com/facebook/jest/pull/8918
* Updated jest-junit (not a Jest package) but blackholed it internally because it is only used for open source CI.
* Updated some API calls we use from Jest to account for breaking changes
* Made two absolutely egrigious changes to existing product code tests to make them still pass as our match of async/await, fake timers and then/promise using `setImmediate` is tripping up `regenerator` with `Generator is already run` errors in Jest 25. These tests should probably be rewritten.
* Locked everything to the same `resolve` version that we were already using, otherwise it was somehow pulling in 1.16 even though nothing internally uses it.

Changelog: [General] Update Jest

Reviewed By: rickhanlonii

Differential Revision: D21064825

fbshipit-source-id: d0011a51355089456718edd84ea0af21fd923a58

* Apply placeholderColor to TextInput component

Summary:
Changelog: [Internal]

TextInput's `placeholderTextColor` prop was being ignored. This diff fixes that.

Reviewed By: JoshuaGross

Differential Revision: D21064118

fbshipit-source-id: 33f148c355cee846db010153e0c65ea43155c3c9

* Fix mistake in swapping left/right layout properties

Summary:
Changelog: [Internal]

We were assigned `undefined` value to incorrect edge, instead of `YGEdgeLeft` it should have been `YGEdgeRight`.
If node has `YGEdgeRight` value, it needs to be reassigned to `YGEdgeEnd` and its original value set to undefined.

Reviewed By: mdvacca

Differential Revision: D21095234

fbshipit-source-id: fbecd9b7e6670742ad4a4bb097760aa10eec8685

* Fixed incorrect owner assignment in YGNode move constructor

Summary:
Assigning self as an owner makes a cycle which is obviously a bug.

Changelog: [Internal] Small change in Yoga (should not affect RN).

Reviewed By: SidharthGuglani

Differential Revision: D21111423

fbshipit-source-id: 1835561c055ac827f5ce98a044f25aed0d1845a5

* Easy diff to add a TODO

Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands

This was orginally added D17142507

changelog: [Internal] Internal change

Reviewed By: JoshuaGross

Differential Revision: D21137348

fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db

* Add support for generating custom messages

Summary:
Until now we've generated scaffolding entirely based on the official devtools
protocol spec. This diff adds support for defining custom domains in `custom.json`
which will be merged with the upstream protocol JSON definition.

ChangeLog: [Internal] Add support for Hermes-specific CDP messages

Reviewed By: bestander

Differential Revision: D20754605

fbshipit-source-id: a8075f81816a40114d1a3332192c7aa076b17848

* Implement Hermes.setPauseOnLoad

Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.

The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.

Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call

Reviewed By: bestander

Differential Revision: D20754604

fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909

* Switch isPackagerRunning to a class method.

Summary:
This diff exports `isPackagerRunning` as a class method to be used without and instance.

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21094414

fbshipit-source-id: 44becb59e3c08d66e4992c4c1b32d6efcd4fe257

* Fabric: Fixed `getDirtied` vs `isDirty` in `YogaLayoutableShadowNode`

Summary:
This is quite a fateful mistake. `getDirtied()` returns the pointer to a function which is obviously a mistake here; we should use `isDirty()` instead.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028569

fbshipit-source-id: 95212b31f4e32d51c594d5209f295397af3f1252

* Fabric: More strict policies to dirty Yoga nodes in YogaLayoutableShadowNode

Summary:
Yoga uses a dirty flag to re-layout nodes. In normal, single-threaded approach the policy for dirtying is simple: if a node was changed, we need to dirty it. In the Concurrent Yoga approach, those rules are not so simple, and it seems we haven't formalized those rules yet.

Investigating some layout issues that we have in Fabric, I tend to believe that we don't dirty as much we should. Hense this change adds mode dirtying.

Reviewed By: JoshuaGross

Differential Revision: D21092815

fbshipit-source-id: 4603c97ccb79efcdf5e6a4cc450ebe61b63effb3

* Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors (#28703)

Summary:
Per discussion in https://github.com/react-native-community/releases/issues/186 the iOS `PlatformColor()` function is documented to use the semantic color names provided by the system.   The referenced HIG documentation itself links to the `UIColor` documentation for semantic colors names.   However, these names differ depending on if you are viewing the new Swift API docs or the Objective C docs.   The current Objective C implementation in react-native assumes Objective C UIColor selector names that are suffixed 'Color'.   But in Swift, Apple provides a Swift Extension on UIColor that makes aliases without the the 'Color' suffix and then makes the original selectors invalid presumably via `NS_UNAVAILABLE_SWIFT`.

Since both selector names are valid depending on if you are using Objective C or Swift, let's make both forms be legal for `PlatformColor()`.   In `RCTConvert.m` there is a dictionary of legal selector names.   The code already supports the ability to have names be aliases of other selectors via a RCTSelector metadata key.   The change adds code to the initialization of the map: it iterates over the keys in the map, which are all ObjC style UIColor selectors, and creates aliases by duplicating the entries, creating key names by stripping off the ObjC "Color" suffix, adds the RCTSelector key referring to the original and then appends these new Swift aliases to the map.

## Changelog

[iOS] [Changed] - Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors
Pull Request resolved: https://github.com/facebook/react-native/pull/28703

Test Plan:
The PlatformColorExample.js is updated to use the new, shorter Swift selector names.   There are still other examples in the same file and in unit tests that exercise the ObjC selector names.

<img width="492" alt="PlatformColor" src="https://user-images.githubusercontent.com/30053638/79809089-89ab7d00-8324-11ea-8a9d-120b92edeedf.png">

Reviewed By: shergin

Differential Revision: D21147404

Pulled By: TheSavior

fbshipit-source-id: 0273ec855e426b3a7ba97a87645859e05bcd4126

* Update Differ test

Summary:
Update differ test so it passes again. Previously to D21111423 (I think) nodes were being incorrectly detected as updated even if they weren't different, so now there are fewer unnecessary Update mutations generated.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21148647

fbshipit-source-id: cab6e3ecd0a457e1ac3155b3468bcc56663dab0b

* Enable Yoga logging in Fabric Debug

Summary:
This diff extends Fabric to support Yoga logging

changeLog: [Internal] Internal changes in Fabric to enable yoga logging

Reviewed By: JoshuaGross

Differential Revision: D21150195

fbshipit-source-id: a2e8308a79a7b422bf9ecc3a65f822b305f02c5d

* Easy diff to document in code how to enable logging of Shadow Tree instrospection

Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection

changeLog: [Internal] Internal change used on Fabric

Reviewed By: JoshuaGross

Differential Revision: D21150196

fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd

* Flip text alignment in case layout direction is RTL

Summary:
Changelog: [Internal]

Flip text alignment in case layout direction is RTL.

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21130371

fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b

* Daily `arc lint --take GOOGLEJAVAFORMAT`

Reviewed By: zertosh

Differential Revision: D21154707

fbshipit-source-id: 11956915c265f98e286638b91d66d51545e3a311

* Upgrade Flipper to 0.37.0 (#28545)

Summary:
Bump flipper to 0.37 for both iOS and Android

## Changelog

[Android] [Changed] - Upgrade Flipper to 0.37.0
[iOS] [Changed] - Upgrade Flipper to 0.37.0
Pull Request resolved: https://github.com/facebook/react-native/pull/28545

Test Plan: RNTester build pass

Reviewed By: rickhanlonii

Differential Revision: D20930069

Pulled By: hramos

fbshipit-source-id: a7cb719da3e51e6a42d27d5e64bc664398d0d3c5

* Upgrade babel-eslint in xplat/js

Summary:
`babel-eslint` is the parser you can supply to ESLint based off of Babel.

`babel-eslint` 10.1.0 is the newest production version of `babel-eslint`.

There are very few changes between 10.0.1 (the lowest previous version) and 10.1.0. There are only 3 non-version-bump commits: 2 bug fixes and enabling parsing of Flow enums.

The only project that was on a lower version than 10.0.1 was `/xplat/js/RKJSModules/Libraries/Relay/oss/__github__` - test below

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21055850

fbshipit-source-id: bae0d8af5c6d833a4dbb0ad775c8e5e78ead1051

* RN: Create `RootTag` Type

Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.

This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21127173

fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0

* RN: Add `RootTag` Type to TurboModule

Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).

This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:

- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: RSNara

Differential Revision: D21127170

fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb

* RN: Fix Codegen Schema Buck Dependency (#28719)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719

The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21162993

fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658

* Flow 0.123.0 in xplat/js

Summary:
Changelog: [Internal]

## Sync of generated files

Ran
```
js1 upgrade www-shared -p core_windowless
```
but had to manually revert
```
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLoggerType.flow.js
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLogger.js
```
because they introduced more errors

## Flow version bump
```
~/fbsource/fbcode/flow/facebook/deploy_xplat.sh 0.123.0
```

Reviewed By: gkz

Differential Revision: D21159821

fbshipit-source-id: e106fcb43e4fc525b9185f8fc8a246e6c3a6b14f

* Remove outdated metro type definitions

Summary:
RN itself does not depend on Metro any longer, which is abstracted away into the CLI. I don't think we need those type definitions any longer as we have proper Metro definitions internally. I'm removing them because they keep showing up in biggrep when I look for things.

Changelog: [Internal]

Reviewed By: GijsWeterings

Differential Revision: D21089924

fbshipit-source-id: 2845277af12dae0f0baefaf85adefffb6ef9f2a5

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D21175893

fbshipit-source-id: 101734c1b968ce241a15648efdcaeabbd789952d

* remove tvOS from template (#28706)

Summary:
According to the [0.62 blog post](https://reactnative.dev/blog/2020/03/26/version-0.62), Apple TV support has moved to react-native-tvos.
The template still contains info.plist for tvOS, so I've removed them for future releases.

## 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] [Removed] - Removed tvOS related files from the template
Pull Request resolved: https://github.com/facebook/react-native/pull/28706

Test Plan: run `react-native init TestTemplate` and remove tvOS related files and verified that iOS and Android runs on emulator.

Differential Revision: D21182211

Pulled By: hramos

fbshipit-source-id: 41d2e19e5158d7ec103a37c01a93cf511fc1e4c9

* Fabric: `ConcreteShadowNode::initialStateData()` now accepts a `ShadowNodeFamilyFragment` instead of just a `SurfaceId`

Summary:
We need it to be able pass an `EventEmitter` object to constructed concrete State objects.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21169581

fbshipit-source-id: 3eef0310de7e2f061108aa85c1a39678a43fe85e

* Fabric: Introducting `ShadowNodeFamilyFragment::Value`

Summary:
`ShadowNodeFamilyFragment::Value` is a value couter-part type for `ShadowNodeFamilyFragment`.
We need that to be able safely copy data stored inside a `ShadowNodeFamilyFragment` object.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: kacieb

Differential Revision: D21169580

fbshipit-source-id: 1a485e1b2ae47bc7da9476a60466934ac9d61366

* Overhaul RCTTurboModule creation and initialization

Summary:
## Problems:
In my investigation of T65656635, I realized that the TurboModule system has a number of problems:
- In TurboModules, we use 1 lock to create n TurboModules. We should change this setup to n locks for n TurboModules. This way, two threads creating two different NativeModules don't compete for the same lock. Also, this is how it's done in Android (TurboModules & NativeModules), and iOS (NativeModules).
- In TurboModules, we don't calculate "requires main queue setup" faithfully. In the legacy system, if a NativeModule has a custom `init` method or a custom `constantsToExport` method, it "requires main queue setup" with a warning.
- In TurboModules, we don't create the NativeModule on the main queue, if "requires main queue setup" is true. Instead, the NativeModule is always created on the thread that requires it.
- In TurboModules, we don't perform any concurrency control around `id<RCTTurboModule>` setup. We should.

## What this diff does
In this diff, I fixed all the aforementioned issues by re-implementing `provideRCTTurboModule:`.

**Algorithm Notes:**
- **Gist:** When `n` threads race to create NativeModule `x`, only the first thread creates and sets up `x`. All others are told to wait. Once the creator thread finishes its job, it notifies all other waiting threads, which then wake up and return the newly created NativeModule. This algorithm was initially implemented in NativeModules for Android inside (ModuleHolder.java). I modified and implemented it for TurboModules for Android, and now this diff implements it for TurboModules for iOS.
- The TurboModule cache is replace with a TurboModuleHolder map. A TurboModuleHolder manages the creation lifecycle of a TurboModule, and holds a condition variable and mutex for doing concurrency control around it. When the bridge invalidates, in TurboModuleManager, we set the `invalidating` flag to true, which prevents the insertion of new entries into the TurboModuleHolder map.
- I added a `std::mutex` to serialize calls into the TurboModuleManagerDelegate, so we don't get races if the delegate isn't thread-safe.

Changelog:
[iOS][Fixed] - Re-implement RCTTurboModuleManager provideRCTTurboModule:

Reviewed By: shergin

Differential Revision: D21170099

fbshipit-source-id: 8792812c2237d3bfc80c9834c818e011de85b0ea

* Fix folly::dynamic crash when attaching a debugger to Hermes

Summary:
folly_futures was compiled with and exported -DFOLLY_MOBILE=1, while
folly_json did not. This flag disables fancy F14 data structures for
folly::dynamic in favor of a simple std::unordered_map.

This caused inlined/templated code from modules depending on
folly_futures to disagree with the implementations in folly_json,
leading to a crash.

The only such libraries were libhermes-inspector and (transitively)
libhermes-executor-debug, and these only use folly::dynamic for CDP
serialization, which is why the problem was not more apparent.

Changelog: [Internal] Fix crash when attaching a Hermes debugger

Reviewed By: mhorowitz

Differential Revision: D21193307

fbshipit-source-id: 2b795bb6f4f7f991e2adaacec62d62616117322b

* Set black as default text color for <TextInput/> on iOS (#28708)

Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested …
HeyImChris pushed a commit to HeyImChris/react-native-macos that referenced this issue Sep 2, 2021
* Update default Podfile to not depend on a path (#28572)

Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.

While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.

https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9

Unfortunately, due to the way Ruby works, this completely hides the path away from the users.

Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.

With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.

https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10

This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.

As a result, we don't have to change the paths here whether we're running monorepo or not.

## Changelog

[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: https://github.com/facebook/react-native/pull/28572

Differential Revision: D20945194

Pulled By: TheSavior

fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27

* Upgrade Prettier in Xplat to version 1.19.1

Summary:
Upgrades Prettier in Xplat to 1.19.1
Ignores upgrading packages on already on versions greater than 1.19.1

Changelog: [Internal]

allow-large-files
bypass-lint

(Note: this ignores all push blocking failures!)

Reviewed By: gkz, cpojer

Differential Revision: D20879147

fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d

* Stop using get_fbobjc_enable_exception_lang_compiler_flags_DEPRECATED in xplat

Summary:
Old deprecated function.

Changelog: [Internal]

Reviewed By: nlutsenko

Differential Revision: D20148856

fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469

* Add ProGuard rule for hermes (#28571)

Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
https://github.com/facebook/react-native/issues/28270

## 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] - ProGuard rule for hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/28571

Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.

Reviewed By: cpojer

Differential Revision: D20947095

Pulled By: hramos

fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d

* Move CheckBox JS files to FB Internal

Summary:
Move CheckBox JS files to FB internal

## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D20910775

fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327

* fix: ripple should be applied even when borderless == false (#28526)

Summary:
With current master, when you render `<Pressable android_ripple={{borderless: false}}>`, there is no ripple effect at all.

I think the expected behavior is to have ripple with default color and radius, just not borderless.

This was how it was done (by me) in https://github.com/facebook/react-native/pull/28156/files but in the import process, the implementation was changed: https://github.com/facebook/react-native/commit/bd3868643d29e93610e19312571a9736df2cbdf8 so either this PR is a fix or you can just close it (but I'd be curious why).

## 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] [fixed] - ripple should be applied even when borderless == false
Pull Request resolved: https://github.com/facebook/react-native/pull/28526

Test Plan:
`<Pressable android_ripple={{borderless: false}}>` on master

![SVID_20200404_123614_1](https://user-images.githubusercontent.com/1566403/78424971-6b315a80-7671-11ea-8be4-5fea428bc556.gif)

`<Pressable android_ripple={{borderless: false}}>` in this PR

![SVID_20200404_122754_1](https://user-images.githubusercontent.com/1566403/78424986-8bf9b000-7671-11ea-9804-37cd58dbb61e.gif)

Differential Revision: D20952026

Pulled By: TheSavior

fbshipit-source-id: df2b95fc6f20d7e958e91805b1a928c4f85904f1

* Remove ColorAndroid function as it adds no value over PlatfromColor (#28577)

Summary:
This change removes the `ColorAndroid` API.   It was added more as a validation tool than as something useful to a developer.   When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc.    Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`.    Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.

## 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] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577

Test Plan: RNTester in both iOS and Android was tested.   Jest tests, Flow checks, Lint checks all pass.

Reviewed By: cpojer

Differential Revision: D20952613

Pulled By: TheSavior

fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0

* iOS: mark some old NativeModule targets with depslint_never_remove

Summary:
Label some BUCK targets properly.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D20960917

fbshipit-source-id: 42fa2266105b6c3dd5108a1b56035a19a95cd61f

* Update Gradle Wrapper to 6.3 (#28173)

Summary:
```
Welcome to Gradle 6.3!

Here are the highlights of this release:
 - Java 14 support
 - Improved error messages for unexpected failures

For more details see https://docs.gradle.org/6.3/release-notes.html
```

## Changelog

[Android] [Changed] - Update Gradle Wrapper to 6.3
Pull Request resolved: https://github.com/facebook/react-native/pull/28173

Test Plan: Build project

Differential Revision: D20958894

Pulled By: mdvacca

fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f

* Fix crash inside RCTRedBox when trying to present same UIViewController twice

Summary:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash

We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:

> A Boolean value indicating whether the view controller is being presented.

Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#

 ---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.

```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```

Changelog: Fix crash caused by presenting view controller twice from RCTRedBox

Reviewed By: PeteTheHeat

Differential Revision: D20946645

fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81

* Animated: Early detection of division by zero in AnimatedDivision

Summary:
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] Early crash in AnimatedDivision in case of division by zero.

Reviewed By: mdvacca

Differential Revision: D20969087

fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344

* Fabric: Controlling DifferentiatorMode via ReactNativeConfig

Summary:
Now we can control the differentiator mode via MC.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: fkgozali

Differential Revision: D20978857

fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4

* Upgrade Hermes dependency to 0.5.0

Summary:
Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`.

Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0

allow-large-files

Reviewed By: mhorowitz

Differential Revision: D20998564

fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50

* Set width/height also to Undefined when we change the measure mode to Undefined

Summary:
Make sure width/height is always passed as Undefined when measure mode is changed to Undefined.

Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined

Reviewed By: alickbass

Differential Revision: D20029838

fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304

* Remove redundant input from TextInput

Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D21016502

fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088

* Update RNTester AppDelegate for changes made to SurfacePresenter API (#28580)

Summary:
This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`.

## Changelog

[Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/28580

Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled.

Reviewed By: hramos

Differential Revision: D20966067

Pulled By: mdvacca

fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1

* Retryable ViewCommand exceptions shouldn't crash

Summary:
Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing).

Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow.

If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely.

The only concern I have with landing this is the perf implications of putting a try/catch inside this loop.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21023213

fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82

* Remove setMostRecentEventCount from TextInput view commands

Summary:
Changelog: [Internal]

We don't use view command `setMostRecentEventCount`, let's get rid of it.

Reviewed By: JoshuaGross

Differential Revision: D21016600

fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b

* label-actions: Add canned response for upgrade issues

Summary:
Enhance the label-actions config and support a "Type: Upgrade Issue" label.
- Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied.
- Close the issue.

Changelog:
[Internal] label-actions: Add canned response for upgrade issues

Reviewed By: cpojer

Differential Revision: D20974607

fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56

* Yoga Podspec: Export YGNode and YGStyle headers (#997)

Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.

The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.

This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.

I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.

Changelog:

[Internal] - Yoga Podspec: Export YGNore and YGStyle headers

Pull Request resolved: https://github.com/facebook/yoga/pull/997

Reviewed By: hramos

Differential Revision: D20966075

Pulled By: mdvacca

fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e

* Add logging to catch null TurboModules

Summary:
We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027984

fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6

* Remove module cache from ReactPackageTurboModuleManagerDelegate

Summary:
This cache is unnecessary, because:
1. TurboModuleManager caches all created TurboModules
2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`.

This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21027998

fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7

* Control concurrent calls into TMMDelegate from TMM

Summary:
In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created.

## The problem:
What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees.

## The fix
`TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood).

Changelog:
[Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager

Reviewed By: mdvacca

Differential Revision: D21025965

fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df

* Bump eslint-plugin-react-native-community version to 1.1.0

Summary:
This release will include the new platform-colors rule.

Changelog: [Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21022163

fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7

* Update Babel to 7.8.x/7.9.x

Reviewed By: motiz88

Differential Revision: D20697095

fbshipit-source-id: ef35d02da0916109ce528d3026f7ca0956911dda

* fix: do not throw on missing `cliPath`, use the default value (#28625)

Summary:
The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file.

In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change.

## Changelog

[ANDROID] [INTERNAL] - Don't require `cliPath`
Pull Request resolved: https://github.com/facebook/react-native/pull/28625

Test Plan:
Run Android project, everything works.
Provide custom `cliPath`, it gets respected

Reviewed By: cpojer

Differential Revision: D21044222

Pulled By: TheSavior

fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e

* Fix CIRCLE_PR_NUMBER may not always be set (#28640)

Summary:
This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork.

## Changelog

[Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set
Pull Request resolved: https://github.com/facebook/react-native/pull/28640

Test Plan: Report bundle size step should pass on both this PR and https://github.com/facebook/react-native/issues/28641.

Reviewed By: cpojer

Differential Revision: D21045553

Pulled By: TheSavior

fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608

* Add "Open Debugger" and "Open React DevTools" to iOS dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D20784270

fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd

* Changed iOS LaunchScreen from xib to storyboard (#28239)

Summary:
> Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens.

Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b).

Community discussion: https://github.com/react-native-community/discussions-and-proposals/issues/209

## Changelog

Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required.

[iOS] [Deleted] - Deleted LaunchScreen.xib
[iOS] [Added] - Added LaunchScreen.storyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/28239

Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one.

Reviewed By: cpojer

Differential Revision: D20408892

Pulled By: hramos

fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a

* Switch over to JavaTurboModule::InitParams

Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).

**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.

## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
 public:
  struct InitParams {
    std::string moduleName;
    jni::alias_ref<JTurboModule> instance;
    std::shared_ptr<CallInvoker> jsInvoker;
    std::shared_ptr<CallInvoker> nativeInvoker;
  };
```

All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments.  Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.

## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.

## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.

## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.

## Commands run

Reviewed By: fkgozali

Differential Revision: D21035208

fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c

* RN: Shrinkwrap Text Layout (Android)

Summary:
When text is in a constrained parent view using `maxWidth`, long text may wrap. When the text wraps, the final width is dependent on the word breaking strategy and text content. This means that the text width is not necessarily `maxWidth`.

However, the current way that we compute text layout does not shrinkwrap the text width as much as possible. This leads to visual gaps to the end-side of wrapped text.

This changes the text layout slightly so that we use the length of the longest line.

This bug only exists on Android. After this change, Android behaves like iOS.

Changelog:
[Android] [Fixed] - Fixed excessive space in Text view with word-wrapping

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21056031

fbshipit-source-id: e9b7793f2632caafcce69bc15bac61330b0ed958

* (eslint-config) update community eslint plugin in eslint config (#28642)

Summary:
Updating the community eslint-plugin used in the eslint-config to the latest version.

expecting new eslint-config version to be released with this change so that it can be included in new project template for 0.63 https://github.com/react-native-community/releases/issues/186

## 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 community eslint plugin in the eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/28642

Test Plan: yarn lint passes

Differential Revision: D21048976

Pulled By: cpojer

fbshipit-source-id: 2c3ec0ef450cf357d8c88db7873f4ca1154b2034

* chore: update CLI to the latest version (#28623)

Summary:
Bumps CLI to the latest version, needed by https://github.com/facebook/react-native/pull/28572 to work.

## Changelog

[INTERNAL] - Bump CLI to latest
Pull Request resolved: https://github.com/facebook/react-native/pull/28623

Reviewed By: hramos

Differential Revision: D21017766

Pulled By: cpojer

fbshipit-source-id: 62a873923c58f8752edb0394db7e6dfceed92485

* Add "Open Debugger" and "Open React DevTools" to Android dev menu

Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20784279

fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb

* Remove the post install step (#28651)

Summary:
Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5.

cc alloy

## 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
-->

[Flipper] [Template] - Remove the post install step for Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/28651

Test Plan: Tested a newly created RN app without post install step and it built successfully.

Reviewed By: passy

Differential Revision: D21064653

Pulled By: priteshrnandgaonkar

fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac

* Revert D21064653: Remove the post install step

Differential Revision:
D21064653

Original commit changeset: da56d0754d91

fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124

* Remove out of date TODO

Summary:
No longer relevant.

Changelog: [Internal]

Reviewed By: mhorowitz

Differential Revision: D21070955

fbshipit-source-id: 11b0384501b2780f5ac41899b5e8bbb4f7a4d730

* RNTester LayoutAnimation example: add more options

Summary:
Add more options to the LayoutAnimation example so it's easier to test more features of LayoutAnimations.

1) Add an option to animate reordering of views
2) Make animations slower, so it's easier to see what's going on and easier to trigger race conditions
3) Add options to mutate without animation, to test interrupting existing animations

Changelog: [Internal] Updated Catalyst RNTester LayoutAnimation example with additional options

Reviewed By: mdvacca

Differential Revision: D21050309

fbshipit-source-id: 1daba4fd487693c34a2d40eb39a68c7d03c24f93

* Add a "reparenting" LayoutAnimation example that animates flattening/unflattening

Summary:
Simple test to see what it looks like when view flattening/unflattening is animated with LayoutAnimations.

Changelog: [Internal] adding another example to LayoutAnimations example

Reviewed By: mdvacca

Differential Revision: D21074805

fbshipit-source-id: 551ed740f0ab5c5adcb19f5c35e932b8983cd108

* Fix jsi cmake include dirs (#207)

Summary:
I'm trying to use JSI for a React Native custom module. I saw these existing examples where the JSI API is used in the context of a CMakeLists.txt:
https://github.com/terrysahaidak/host-object-test/blob/master/libs/android-jsi/test-jsi/src/main/cpp/CMakeLists.txt
https://github.com/ericlewis/react-native-hostobject-demo/pull/4/files#diff-834320be1b4e4016bac27c05dcd17fb9
In both cases, they manually grab the include directories and jsi.cpp from node_modules/react-native, but I also saw that node_modules/react-native/ReactCommon/jsi/jsi already has a CMakeLists.txt that appears to be intended to provide a jsi static lib, so I tried to pull this into my own CMakeLists.txt like this:
```
add_subdirectory(${RN_DIR}/ReactCommon/jsi/jsi ${CMAKE_CURRENT_BINARY_DIR}/jsi)
...
target_link_libraries(MyLib jsi)
```
Unfortunately when doing this, the consuming project still doesn't see the correct include directories. The change I'm proposing here is to use `target_include_directories` and declare that `..` is a public (to consumers) include directory for the library named `jsi`. With this change, you can do what I showed above to consume the jsi lib by just pulling in the CMakeLists.txt file into your own CMakeLists.txt file.

Changelog: [General][Fixed] Fix jsi cmake include dirs

Pull Request resolved: https://github.com/facebook/hermes/pull/207

Reviewed By: willholen

Differential Revision: D21074270

Pulled By: tmikov

fbshipit-source-id: 7d9ec3255f57a16c0b2be489dffa4540727738a1

* Resolve `kind-of` vulnerability by bumping to 6.0.3

Summary:
https://github.com/advisories/GHSA-6c8f-qphg-qjgp

Changelog:
[General][Changed] Updated transitive dependency kind-of to 6.0.3 to resolve vulnerability

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21077747

fbshipit-source-id: d5c19b21b665130c6423f5caeddcd6378bac7dcb

* Move CheckBox Android files to FB internal (#28658)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28658

This moves the Java files to FB internal and updates all the buck files.

## Changelog:

[Android] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.

Reviewed By: cpojer

Differential Revision: D21066998

fbshipit-source-id: 76821fcae899ff7342697ea7dd4737ef3b008213

* Part 1: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.

## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.

## Commands run
```
function update-codegen() {
  pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}

> update-codegen
```

Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036266

fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086

* Part 2: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035209.

## Changes
- Codemod all ObjC NativeModule `getTurboModuleWithJsInvoker:nativeInvoker:perfLogger` methods to `getTurboModule:(const ObjCTurboModule::Args)`

## Script
```
var withSpaces = (...args) => args.join('\s*')

var regexString = withSpaces(
  '-',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<turboModuleClass>(facebook::react::|react::|::|)TurboModule)',
  '>',
  '\)',
  'getTurboModuleWithJsInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(?<fbNamespace>(facebook::react::|react::|::|))CallInvoker',
  '>',
  '\)',
  '(?<jsInvokerInstance>[A-Za-z0-9]+)',
  'nativeInvoker',
  ':',
  '\(',
  'std::shared_ptr',
  '<',
  '(facebook::react::|react::|::|)CallInvoker',
  '>',
  '\)',
  '(?<nativeInvokerInstance>[A-Za-z0-9]+)',
  'perfLogger',
  ':',
  '\(',
  'id',
  '<',
  'RCTTurboModulePerformanceLogger',
  '>',
  '\)',
  '(?<perfLoggerInstance>[A-Za-z0-9]+)',
  '{',
  'return',
  'std::make_shared',
  '<',
  '(?<specName>(facebook::react::|react::|::|)Native[%A-Za-z0-9]+SpecJSI)',
  '>',
  '\(',
  'self',
  ',',
  '\k<jsInvokerInstance>',
  ',',
  '\k<nativeInvokerInstance>',
  ',',
  '\k<perfLoggerInstance>',
  '\)',
  ';',
  '}',
)

var replaceString = `- (std::shared_ptr<$<turboModuleClass>>) getTurboModule:(const $<fbNamespace>ObjCTurboModule::InitParams &)params
{
  return std::make_shared<$<specName>>(params);
}`

const exec = require('../lib/exec');
const abspath = require('../lib/abspath');
const relpath = require('../lib/relpath');
const readFile = (filename) => require('fs').readFileSync(filename, 'utf8');
const writeFile = (filename, content) => require('fs').writeFileSync(filename, content);

function main() {
  const tmFiles = exec('cd ~/fbsource && xbgs -n 10000 -l getTurboModuleWithJsInvoker:').split('\n').filter(Boolean);

  tmFiles
    .filter((filename) => !filename.includes('microsoft-fork-of-react-native'))
    .map(abspath)
    .forEach((filename) => {
      const source = readFile(filename);
      const newSource = source.replace(new RegExp(regexString, 'g'), replaceString);

      if (source == newSource) {
        console.log(relpath(filename));
      }

      writeFile(filename, newSource);
    });
}

if (!module.parent) {
  main();
}
```

## Re-generating diff
```
> hg revert -r .^ --all
> node index.js # run script
```

Changelog: [iOS][Changed] - Make all ObjC NativeModules create TurboModules using ObjCTurboModule::Args

Reviewed By: PeteTheHeat

Differential Revision: D21036265

fbshipit-source-id: 404bcc548d1775ef23d793527606d02fe384a0a2

* Part 3: Update RCTTurboModuleManagerDelegate to use ObjCTurboModule::InitParams

Summary:
## Summary
Please check out D21035208.

## Changes
- Update `RCTTurboModuleManagerDelegate getTurboModule:instance:jsInvoker:nativeInvoker:perfLogger` to use `RCTTurboModuleManagerDelegate getTurboModule:(const ObjCTurboModule::InitParams)`
- Update all implementations of `RCTTurboModuleManagerDelegate` in accordance with this API change

Changelog:
[iOS][Changed] - Make RCTTurboModuleManagerDelegate create TurboModules via ObjCTurboModuleManager::InitParams

Reviewed By: PeteTheHeat

Differential Revision: D21036272

fbshipit-source-id: c16002c47db26e2ba143fc1080afe9e2fe1e7816

* chore: update `./scripts/test-manual-e2e.sh` (#28653)

Summary:
Recent changes broke the script - wrong path to open `RNTesterPods.xcworkspace` and other scripts - we change dir with `cd`.

Another change is incorrect use of `RNTesterProject.xcodeproj` instead of a `xcworkspace`.

This PR is a simple and short fix to make it run.

## Changelog

[INTERNAL] - chore: update `./scripts/test-manual-e2e.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/28653

Test Plan: Run `./scripts/test-manual-e2e.sh`. Things work.

Differential Revision: D21079792

Pulled By: hramos

fbshipit-source-id: 6bdb8be016f044852ed216ec53f80db40c84b5fd

* use default value of enums YGDirection and YGMeasureMode instead of -1

Summary:
Changelog:
[Internal][Yoga] YGDirection variable was initialized incorrectly by casting -1 to YGDirection. Changing it to default value of direction

Same for YGMeasureMode.

Reviewed By: pasqualeanatriello

Differential Revision: D20869042

fbshipit-source-id: 7bfe490193321baae875ef6fb49a938851950c9f

* fix typo as there is no file called YGJNI.cpp (#990)

Summary:
fix typo in `YogaJNIBase.java` as there is no such file called `YGJNI.cpp`
Pull Request resolved: https://github.com/facebook/yoga/pull/990

Reviewed By: pasqualeanatriello

Differential Revision: D20735102

Pulled By: SidharthGuglani

fbshipit-source-id: 3f9f4d78ba390feae3451330f997a221ab4ec70e

* Remove unused packages from xplat/js/package.json

Summary:
We have a large amount of small packages that are completely unused, or only have one call site. This diff cleans up a lot of them and reduces node_modules by 12 MiB (down to 187).

Changelog: [Internal]

Reviewed By: motiz88

Differential Revision: D21088213

fbshipit-source-id: 5fa7d3da5cbe744b0d9d3e3450d6135c1488ee79

* Make ColorValue public in StyleSheet.js

Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.

Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet

Reviewed By: TheSavior

Differential Revision: D21076969

fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab

* Fabric: `LayoutableShadowNode:getLayoutMetrics` is not a virtual method anymore

Summary:
We don't use it as vitrual anymore (setLayoutMetrics is a non-virtual method already), so it does not need to be marker virtual.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028572

fbshipit-source-id: 99f86fdd4cf2f5972034d9058d7b82bdc8680187

* Fabric: Proper traits for `ImageShadowNode` and `ViewShadowNode`

Summary:
* <Image> must be a leaf node; having a proper trait will fail earlier in case of misuse (mounting something inside).
* <View> must have a `View` trait because it's for what that trait is.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D21028573

fbshipit-source-id: 457716d4661333eb2357f34316f3e495ab4fda24

* Fabric: "Attempt to mutate a sealed object." is now an assert (not exception)

Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028571

fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9

* Fabric: Implementation of `getDebugDescription` for `std::array`

Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028570

fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd

* Fabric: `componentregistry` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885163

fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af

* Fabric: `scheduler` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885645

fbshipit-source-id: 8148bd934879802b076261ed86fa78acf0a07ed3

* Fabric: `templateprocessor` module was decoupled from `uimanager`

Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20885646

fbshipit-source-id: b8e3199c0eacc57a5be1481595cf97c84f972293

* Migrate deprecated frameInterval to preferredFramesPerSecond (#28675)

Summary:
[frameInterval](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval) was deprecated in favor of [preferredFramesPerSecond](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1648421-preferredframespersecond).

This migrates the deprecated call over.

## 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
-->

[iOS] [Fixed] - Migrate frameInterval to preferredFramesPerSecond
Pull Request resolved: https://github.com/facebook/react-native/pull/28675

Test Plan: Xcode should no longer throw warnings about the deprecated call.

Differential Revision: D21109710

Pulled By: shergin

fbshipit-source-id: 772b9f625d3e22cd4d8cd60bddad57ff8611af54

* Fabric: Fix case of Glog include in MountingTest.cpp (#28616)

Summary:
This pull request changes the include of Glog from `<Glog/logging.h>` to `<glog/logging.h>` in `MountingTest.cpp`. This fixes building on a case-sensitive filesystem.

## Changelog

[Internal] [Fixed] - Fabric: Fix case of Glog include in MountingTest.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/28616

Test Plan: The `include` of Glog no longer causes issues with building `MountingTest.cpp` on a case-sensitive filesystem.

Differential Revision: D21118085

Pulled By: shergin

fbshipit-source-id: c958c54bf88333fd5001127779c855ce8c2666c3

* Fabric: Add Unicode prefix to AttachmentCharacter (#28617)

Summary:
This pull request adds a Unicode `u8` prefix to the string literal returned in `AttributedString.cpp`'s `Fragment::AttachmentCharacter()`.

This fixes the following error when building on MSVC:

```
react\attributedstring\AttributedString.cpp(21): error C4566: character represented by universal-character-name '\uFFFC' cannot be represented in the current code page (1252)
```

## Changelog

[Internal] [Fixed] - Fabric: Add Unicode prefix to AttachmentCharacter
Pull Request resolved: https://github.com/facebook/react-native/pull/28617

Test Plan: The Fabric test suite has been ran on a Clang-based build of Fabric on macOS, and no regressions in it have been noted.

Differential Revision: D21118078

Pulled By: shergin

fbshipit-source-id: c105de5e4edb67fed97ce44153a75d9d380bf588

* Fabric: Fixed incorrect early-return in `UIView+ComponentViewProtocol::updateLayoutMetrics`

Summary:
Before the change, an incorrect (NaN or Inf) values in LayoutMetrics might force an early return in the `updateLayoutMetrics:oldMetrics:` method implementation. This was not correct because the rest of the method also didn't run in this case, so it might force some value to stale.
E.g., imagine we have an instruction that contains NaN size and `display: none`. Previously, the function might just return right before applying sizes and progress the stored "already applied" value of LayoutMetrics which will cause the view being visible even if it should not.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110644

fbshipit-source-id: 501319d7b1dcd5c18f27e0ceca3c8d207485c49b

* Fix border-stroke drawing after resetting border-radius (#28356)

Summary:
This PR fixes incorrect drawing of the View borders on Android, after changing the border-radius back to 0 *(and when no background-color is defined)*.

This happens because the `drawRoundedBackgroundWithBorders` function in ReactViewBackgroundDrawable changes the style on the Paint object to `STROKE`. This style is however never reverted back to `FILL`. This change ensures that the Paint style is set to `FILL` for the full execution of the `drawRectangularBackgroundWithBorders` function.

## Changelog

`[Android] [Fixed] - Fix border-drawing when changing border-radius back to 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28356

Test Plan:
**Faulty situation:**

![ezgif com-video-to-gif](https://user-images.githubusercontent.com/6184593/77153163-9759b280-6a99-11ea-82bb-33a1e0a4934c.gif)

**After the fix:**

![ezgif com-video-to-gif (1)](https://user-images.githubusercontent.com/6184593/77153825-c91f4900-6a9a-11ea-8e0c-a4280b9e72b8.gif)

Differential Revision: D21124741

Pulled By: shergin

fbshipit-source-id: 2044f8e8ad59a58df42b64d7ee8c4ad1d3b562f1

* Fabric: Using proper clock in MountingTelemetryTest

Summary:
Apparently, `std::this_thread::sleep_for` uses a different clock to measure time which causes ofter misalignment with the clock which Telemery uses which makes the test flaky. Using the same clock should fix it.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21116058

fbshipit-source-id: 52dde2e325776d365431a2a957dcc12dfe53f890

* Fix rounded border drawing when border-radius is smaller than border-width (#28358)

Summary:
This PR fixes the drawing of the border rounded edges when the border-radius is small than the border-width. The current implementation capped the possible border-radius making it impossible to set smaller border-radii when using thicker borders. After inspection it was found that the rounded-rect calculation is incorrect.

## Changelog

`[Android] [Fixed] - Fix rounded border-drawing when border-radius is smaller than border-width`
Pull Request resolved: https://github.com/facebook/react-native/pull/28358

Test Plan:
**Faulty situation:**

As you can see, when the border-radius becomes very low, the border is stuck at a minimum value. Only after setting the border-radius fully to 0 is it again rendered correctly.

![ezgif com-video-to-gif (2)](https://user-images.githubusercontent.com/6184593/77183540-c3435b00-6ace-11ea-950d-29a0ea1757bd.gif)

**After the fix:**

![ezgif com-video-to-gif (3)](https://user-images.githubusercontent.com/6184593/77183619-e837ce00-6ace-11ea-93a5-910127d352b7.gif)

Differential Revision: D21124739

Pulled By: shergin

fbshipit-source-id: cefd1776b77b5b9fb335e95fd7fdd7f345579dc4

* Fabric: `ComponentDescriptor::cloneProps()` now never returns the base props objects

Summary:
The diff changes how the `empty raw props` optimization works in `ComponentDescriptor::cloneProps()`. Now it only fires only when the base `props` object is null, which is practically all production cases we have (and care about). (I tried, in a normal run there were no cases where the empty raw props were passed with non-null props.) From the other side, the old behavior that may return the same props objects previously several times created bugs and practically unexpected results and practically disallowed to clone props objects easily.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21110608

fbshipit-source-id: 884807cd8e9c5c3e6cc1c9e4c1f0227259cc21fb

* Upgrade to Jest 25

Summary:
This diff upgrades Jest to the latest version which fixes a bunch of issues with snapshots (therefore allowing me to enable the Pressable-test again). Note that this also affects Metro and various other tooling as they all depend on packages like `jest-worker`, `jest-haste-map` etc.

Breaking changes: https://github.com/facebook/jest/blob/master/CHANGELOG.md

This diff increases node_modules by 3 MiB, primarily because it causes more duplicates of `source-map` (0.8 MiB for each copy) and packages like `chalk` 3.x (vs 2.x). The base install was 15 MiB bigger and I reduced it to this size by playing around with various manual yarn.lock optimizations. However, D21085929 reduces node_modules by 11 MiB and the Babel upgrade reduced node_modules by 13 MiB. I will subsequently work on reducing the size through other packages as well and I'm working with the Jest folks to get rid of superfluous TypeScript stuff for Jest 26.

Other changes in this diff:
* Fixed Pressable-test
* Blackhole node-notifier: It's large and we don't need it, and also the license may be problematic, see: https://github.com/facebook/jest/pull/8918
* Updated jest-junit (not a Jest package) but blackholed it internally because it is only used for open source CI.
* Updated some API calls we use from Jest to account for breaking changes
* Made two absolutely egrigious changes to existing product code tests to make them still pass as our match of async/await, fake timers and then/promise using `setImmediate` is tripping up `regenerator` with `Generator is already run` errors in Jest 25. These tests should probably be rewritten.
* Locked everything to the same `resolve` version that we were already using, otherwise it was somehow pulling in 1.16 even though nothing internally uses it.

Changelog: [General] Update Jest

Reviewed By: rickhanlonii

Differential Revision: D21064825

fbshipit-source-id: d0011a51355089456718edd84ea0af21fd923a58

* Apply placeholderColor to TextInput component

Summary:
Changelog: [Internal]

TextInput's `placeholderTextColor` prop was being ignored. This diff fixes that.

Reviewed By: JoshuaGross

Differential Revision: D21064118

fbshipit-source-id: 33f148c355cee846db010153e0c65ea43155c3c9

* Fix mistake in swapping left/right layout properties

Summary:
Changelog: [Internal]

We were assigned `undefined` value to incorrect edge, instead of `YGEdgeLeft` it should have been `YGEdgeRight`.
If node has `YGEdgeRight` value, it needs to be reassigned to `YGEdgeEnd` and its original value set to undefined.

Reviewed By: mdvacca

Differential Revision: D21095234

fbshipit-source-id: fbecd9b7e6670742ad4a4bb097760aa10eec8685

* Fixed incorrect owner assignment in YGNode move constructor

Summary:
Assigning self as an owner makes a cycle which is obviously a bug.

Changelog: [Internal] Small change in Yoga (should not affect RN).

Reviewed By: SidharthGuglani

Differential Revision: D21111423

fbshipit-source-id: 1835561c055ac827f5ce98a044f25aed0d1845a5

* Easy diff to add a TODO

Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands

This was orginally added D17142507

changelog: [Internal] Internal change

Reviewed By: JoshuaGross

Differential Revision: D21137348

fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db

* Add support for generating custom messages

Summary:
Until now we've generated scaffolding entirely based on the official devtools
protocol spec. This diff adds support for defining custom domains in `custom.json`
which will be merged with the upstream protocol JSON definition.

ChangeLog: [Internal] Add support for Hermes-specific CDP messages

Reviewed By: bestander

Differential Revision: D20754605

fbshipit-source-id: a8075f81816a40114d1a3332192c7aa076b17848

* Implement Hermes.setPauseOnLoad

Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.

The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.

Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call

Reviewed By: bestander

Differential Revision: D20754604

fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909

* Switch isPackagerRunning to a class method.

Summary:
This diff exports `isPackagerRunning` as a class method to be used without and instance.

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21094414

fbshipit-source-id: 44becb59e3c08d66e4992c4c1b32d6efcd4fe257

* Fabric: Fixed `getDirtied` vs `isDirty` in `YogaLayoutableShadowNode`

Summary:
This is quite a fateful mistake. `getDirtied()` returns the pointer to a function which is obviously a mistake here; we should use `isDirty()` instead.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D21028569

fbshipit-source-id: 95212b31f4e32d51c594d5209f295397af3f1252

* Fabric: More strict policies to dirty Yoga nodes in YogaLayoutableShadowNode

Summary:
Yoga uses a dirty flag to re-layout nodes. In normal, single-threaded approach the policy for dirtying is simple: if a node was changed, we need to dirty it. In the Concurrent Yoga approach, those rules are not so simple, and it seems we haven't formalized those rules yet.

Investigating some layout issues that we have in Fabric, I tend to believe that we don't dirty as much we should. Hense this change adds mode dirtying.

Reviewed By: JoshuaGross

Differential Revision: D21092815

fbshipit-source-id: 4603c97ccb79efcdf5e6a4cc450ebe61b63effb3

* Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors (#28703)

Summary:
Per discussion in https://github.com/react-native-community/releases/issues/186 the iOS `PlatformColor()` function is documented to use the semantic color names provided by the system.   The referenced HIG documentation itself links to the `UIColor` documentation for semantic colors names.   However, these names differ depending on if you are viewing the new Swift API docs or the Objective C docs.   The current Objective C implementation in react-native assumes Objective C UIColor selector names that are suffixed 'Color'.   But in Swift, Apple provides a Swift Extension on UIColor that makes aliases without the the 'Color' suffix and then makes the original selectors invalid presumably via `NS_UNAVAILABLE_SWIFT`.

Since both selector names are valid depending on if you are using Objective C or Swift, let's make both forms be legal for `PlatformColor()`.   In `RCTConvert.m` there is a dictionary of legal selector names.   The code already supports the ability to have names be aliases of other selectors via a RCTSelector metadata key.   The change adds code to the initialization of the map: it iterates over the keys in the map, which are all ObjC style UIColor selectors, and creates aliases by duplicating the entries, creating key names by stripping off the ObjC "Color" suffix, adds the RCTSelector key referring to the original and then appends these new Swift aliases to the map.

## Changelog

[iOS] [Changed] - Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors
Pull Request resolved: https://github.com/facebook/react-native/pull/28703

Test Plan:
The PlatformColorExample.js is updated to use the new, shorter Swift selector names.   There are still other examples in the same file and in unit tests that exercise the ObjC selector names.

<img width="492" alt="PlatformColor" src="https://user-images.githubusercontent.com/30053638/79809089-89ab7d00-8324-11ea-8a9d-120b92edeedf.png">

Reviewed By: shergin

Differential Revision: D21147404

Pulled By: TheSavior

fbshipit-source-id: 0273ec855e426b3a7ba97a87645859e05bcd4126

* Update Differ test

Summary:
Update differ test so it passes again. Previously to D21111423 (I think) nodes were being incorrectly detected as updated even if they weren't different, so now there are fewer unnecessary Update mutations generated.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21148647

fbshipit-source-id: cab6e3ecd0a457e1ac3155b3468bcc56663dab0b

* Enable Yoga logging in Fabric Debug

Summary:
This diff extends Fabric to support Yoga logging

changeLog: [Internal] Internal changes in Fabric to enable yoga logging

Reviewed By: JoshuaGross

Differential Revision: D21150195

fbshipit-source-id: a2e8308a79a7b422bf9ecc3a65f822b305f02c5d

* Easy diff to document in code how to enable logging of Shadow Tree instrospection

Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection

changeLog: [Internal] Internal change used on Fabric

Reviewed By: JoshuaGross

Differential Revision: D21150196

fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd

* Flip text alignment in case layout direction is RTL

Summary:
Changelog: [Internal]

Flip text alignment in case layout direction is RTL.

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D21130371

fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b

* Daily `arc lint --take GOOGLEJAVAFORMAT`

Reviewed By: zertosh

Differential Revision: D21154707

fbshipit-source-id: 11956915c265f98e286638b91d66d51545e3a311

* Upgrade Flipper to 0.37.0 (#28545)

Summary:
Bump flipper to 0.37 for both iOS and Android

## Changelog

[Android] [Changed] - Upgrade Flipper to 0.37.0
[iOS] [Changed] - Upgrade Flipper to 0.37.0
Pull Request resolved: https://github.com/facebook/react-native/pull/28545

Test Plan: RNTester build pass

Reviewed By: rickhanlonii

Differential Revision: D20930069

Pulled By: hramos

fbshipit-source-id: a7cb719da3e51e6a42d27d5e64bc664398d0d3c5

* Upgrade babel-eslint in xplat/js

Summary:
`babel-eslint` is the parser you can supply to ESLint based off of Babel.

`babel-eslint` 10.1.0 is the newest production version of `babel-eslint`.

There are very few changes between 10.0.1 (the lowest previous version) and 10.1.0. There are only 3 non-version-bump commits: 2 bug fixes and enabling parsing of Flow enums.

The only project that was on a lower version than 10.0.1 was `/xplat/js/RKJSModules/Libraries/Relay/oss/__github__` - test below

Changelog: [Internal]

Reviewed By: cpojer

Differential Revision: D21055850

fbshipit-source-id: bae0d8af5c6d833a4dbb0ad775c8e5e78ead1051

* RN: Create `RootTag` Type

Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.

This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21127173

fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0

* RN: Add `RootTag` Type to TurboModule

Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).

This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:

- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: RSNara

Differential Revision: D21127170

fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb

* RN: Fix Codegen Schema Buck Dependency (#28719)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719

The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).

Changelog:
[Internal]

(Note: this ignores all push blocking failures!)

Reviewed By: cpojer

Differential Revision: D21162993

fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658

* Flow 0.123.0 in xplat/js

Summary:
Changelog: [Internal]

## Sync of generated files

Ran
```
js1 upgrade www-shared -p core_windowless
```
but had to manually revert
```
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLoggerType.flow.js
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLogger.js
```
because they introduced more errors

## Flow version bump
```
~/fbsource/fbcode/flow/facebook/deploy_xplat.sh 0.123.0
```

Reviewed By: gkz

Differential Revision: D21159821

fbshipit-source-id: e106fcb43e4fc525b9185f8fc8a246e6c3a6b14f

* Remove outdated metro type definitions

Summary:
RN itself does not depend on Metro any longer, which is abstracted away into the CLI. I don't think we need those type definitions any longer as we have proper Metro definitions internally. I'm removing them because they keep showing up in biggrep when I look for things.

Changelog: [Internal]

Reviewed By: GijsWeterings

Differential Revision: D21089924

fbshipit-source-id: 2845277af12dae0f0baefaf85adefffb6ef9f2a5

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D21175893

fbshipit-source-id: 101734c1b968ce241a15648efdcaeabbd789952d

* remove tvOS from template (#28706)

Summary:
According to the [0.62 blog post](https://reactnative.dev/blog/2020/03/26/version-0.62), Apple TV support has moved to react-native-tvos.
The template still contains info.plist for tvOS, so I've removed them for future releases.

## 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] [Removed] - Removed tvOS related files from the template
Pull Request resolved: https://github.com/facebook/react-native/pull/28706

Test Plan: run `react-native init TestTemplate` and remove tvOS related files and verified that iOS and Android runs on emulator.

Differential Revision: D21182211

Pulled By: hramos

fbshipit-source-id: 41d2e19e5158d7ec103a37c01a93cf511fc1e4c9

* Fabric: `ConcreteShadowNode::initialStateData()` now accepts a `ShadowNodeFamilyFragment` instead of just a `SurfaceId`

Summary:
We need it to be able pass an `EventEmitter` object to constructed concrete State objects.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D21169581

fbshipit-source-id: 3eef0310de7e2f061108aa85c1a39678a43fe85e

* Fabric: Introducting `ShadowNodeFamilyFragment::Value`

Summary:
`ShadowNodeFamilyFragment::Value` is a value couter-part type for `ShadowNodeFamilyFragment`.
We need that to be able safely copy data stored inside a `ShadowNodeFamilyFragment` object.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: kacieb

Differential Revision: D21169580

fbshipit-source-id: 1a485e1b2ae47bc7da9476a60466934ac9d61366

* Overhaul RCTTurboModule creation and initialization

Summary:
## Problems:
In my investigation of T65656635, I realized that the TurboModule system has a number of problems:
- In TurboModules, we use 1 lock to create n TurboModules. We should change this setup to n locks for n TurboModules. This way, two threads creating two different NativeModules don't compete for the same lock. Also, this is how it's done in Android (TurboModules & NativeModules), and iOS (NativeModules).
- In TurboModules, we don't calculate "requires main queue setup" faithfully. In the legacy system, if a NativeModule has a custom `init` method or a custom `constantsToExport` method, it "requires main queue setup" with a warning.
- In TurboModules, we don't create the NativeModule on the main queue, if "requires main queue setup" is true. Instead, the NativeModule is always created on the thread that requires it.
- In TurboModules, we don't perform any concurrency control around `id<RCTTurboModule>` setup. We should.

## What this diff does
In this diff, I fixed all the aforementioned issues by re-implementing `provideRCTTurboModule:`.

**Algorithm Notes:**
- **Gist:** When `n` threads race to create NativeModule `x`, only the first thread creates and sets up `x`. All others are told to wait. Once the creator thread finishes its job, it notifies all other waiting threads, which then wake up and return the newly created NativeModule. This algorithm was initially implemented in NativeModules for Android inside (ModuleHolder.java). I modified and implemented it for TurboModules for Android, and now this diff implements it for TurboModules for iOS.
- The TurboModule cache is replace with a TurboModuleHolder map. A TurboModuleHolder manages the creation lifecycle of a TurboModule, and holds a condition variable and mutex for doing concurrency control around it. When the bridge invalidates, in TurboModuleManager, we set the `invalidating` flag to true, which prevents the insertion of new entries into the TurboModuleHolder map.
- I added a `std::mutex` to serialize calls into the TurboModuleManagerDelegate, so we don't get races if the delegate isn't thread-safe.

Changelog:
[iOS][Fixed] - Re-implement RCTTurboModuleManager provideRCTTurboModule:

Reviewed By: shergin

Differential Revision: D21170099

fbshipit-source-id: 8792812c2237d3bfc80c9834c818e011de85b0ea

* Fix folly::dynamic crash when attaching a debugger to Hermes

Summary:
folly_futures was compiled with and exported -DFOLLY_MOBILE=1, while
folly_json did not. This flag disables fancy F14 data structures for
folly::dynamic in favor of a simple std::unordered_map.

This caused inlined/templated code from modules depending on
folly_futures to disagree with the implementations in folly_json,
leading to a crash.

The only such libraries were libhermes-inspector and (transitively)
libhermes-executor-debug, and these only use folly::dynamic for CDP
serialization, which is why the problem was not more apparent.

Changelog: [Internal] Fix crash when attaching a Hermes debugger

Reviewed By: mhorowitz

Differential Revision: D21193307

fbshipit-source-id: 2b795bb6f4f7f991e2adaacec62d62616117322b

* Set black as default text color for <TextInput/> on iOS (#28708)

Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested …
@facebook facebook locked as resolved and limited conversation to collaborators Oct 1, 2021
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Oct 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs: Triage 🔍 Platform: Android Android applications. Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

6 participants