Merge from upstream through 2020-11-03 #849
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: The codegen output for the native modules in `Libraries/` has been verified to work with RNTester. Publishing a new version as a prerequisite to start using the codegen at build time in open source. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24314972 fbshipit-source-id: edd0066c1cf33ba8e536cc5f145c057ca992eec1
Summary: This NativeModule is actualy not used! Removing this now. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24324362 fbshipit-source-id: 1322c5e072961f1c6c54bfc6dbd562d42f9e5b3f
Summary: The iOS and Android NativeModules are very different. It's better to split the two interfaces, than to have one merged interface. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24324247 fbshipit-source-id: 097273829ffc719eff006ed2dde55f0dd6bd7d95
…SQLiteDBStorage Summary: Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24325260 fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
Summary: Changelog: [internal] Fabric uses view commands instead of setNativeProps. This diff removes what's left of setNativeProps from the core. Reviewed By: JoshuaGross Differential Revision: D24309999 fbshipit-source-id: 70e54f0a984f8c36f77ba2cd59f59fc6923bc832
Summary: RCTSurfaceTouchHandler is not a thread-safe object and must be used (and initialized) on the main thread. Therefore we need to move the initialization to `view` method which is guaranteed to be called on the main thread. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D24290776 fbshipit-source-id: fc1f2f157599aff6fca053451f89bf7cca3c812a
Summary: We will need it soon. Changelog: [Internal] Fabric-specific internal change. Reviewed By: sammy-SC Differential Revision: D24290775 fbshipit-source-id: a312e537a3c3954e709a10c8792b3462b574054a
Summary: In D24324247 (facebook@56c363e), I split NativeLinking into NativeLinkingManager and NativeIntentAndroid. There was this line in NativeLinking.js, that I didn't migrate correctly: ``` export default ((Platform.OS === 'android' ? TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid') : TurboModuleRegistry.getEnforcing<Spec>('LinkingManager')): Spec); ``` I separated this conditional statement into two others: ``` export default TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid'); export default TurboModuleRegistry.getEnforcing<Spec>('LinkingManager'); ``` The problem here is that now on iOS, we're hard requiring IntentAndroid, and on Android, we're hard requiring LinkingManager. Understandably, this started throwing errors in our e2e infra. This diff fixes this problem by: 1. Changing the relevant `getEnforcing` calls into `get` calls. 2. Wrapping all usages of NativeIntentAndroid, and NativeLinkingManager, which are already guarded by `Platform.OS` checks, by a nullthrows. This should satisfy flow. **Note:** NativeIntentAndroid is only used on Android, where it must be available. Similarly, NativeLinkingManager is only used on iOS, where it must be available. Changelog: [Internal] build-break overriding_review_checks_triggers_an_audit_and_retroactive_review Oncall Short Name: fbandroid_sheriff Differential Revision: D24338558 fbshipit-source-id: b0d22cba77e67837834269deaa317dc73d2457dc
Summary:
changelog: [internal]
Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t
# Why is using size_t better when working with indexes.
## 1. Type conversion isn't for free.
Take this example
```
size_t calculate(int number) {
return number + 1;
}
```
It generates following assembly (generated with armv8-a clang 10.0.0):
```
calculate(int): // calculate(int)
sub sp, sp, microsoft#16 // =16
str w0, [sp, microsoft#12]
ldr w8, [sp, microsoft#12]
add w9, w8, #1 // =1
mov w8, w9
sxtw x0, w8
add sp, sp, microsoft#16 // =16
ret
```
That's 9 instructions.
If we get rid of type conversion:
```
size_t calculate(size_t number) {
return number + 1;
}
```
Assembly (generated with armv8-a clang 10.0.0):
```
calculate(unsigned long): // calculate(unsigned long)
sub sp, sp, microsoft#16 // =16
str x0, [sp, microsoft#8]
ldr x8, [sp, microsoft#8]
add x0, x8, #1 // =1
add sp, sp, microsoft#16 // =16
ret
```
Compiler now produces only 7 instructions.
## Semantics
When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.
Reviewed By: JoshuaGross
Differential Revision: D24332248
fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Description
The Codegen deals with "Modules". Hence:
```
type SchemaType = {
modules: {
[moduleName]: ...
}
};
```
Each "Module" has a name, and represents a file. The `moduleName` is the base name of the file. This file can contain a component specification or a NativeModule specification. Hence:
```
type SchemaType = {
modules: {
[moduleName]: ComponentSchema | NativeModuleSchema
}
};
```
The `ComponentSchema` can contain specifications for many different components. Hence:
```
type ComponentSchema = {
type: 'Component'
components: {
[componentName]: ComponentShape
}
}
```
The `NativeModuleSchema` contains
1. Type aliases (no surprises/nothing new).
2. One Flow interface that extends `TurboModule`.
3. Potentially many different NativeModule requires (for now) via `TurboModuleRegistry.get(Enforcing)?<specName>('moduleName')`.
Hence, the shape looks like:
```
type NativeModuleSchema = {
type: 'NativeModule',
aliases: NativeModuleAliasMap, // nothing new
spec: NativeModuleSpec,
moduleNames: $ReadOnlyArray<string>
}
type NativeModuleSpec = {
properties: $ReadOnlyArray<...>,
}
```
## Major Notes
1. We now parse the NativeModule requires (TurboModuleRegistry.get(Enforcing)?<Spec> calls) and record them in the schema.
2. A Codegen "Module" can contain either a Component schema, or a NativeModule schema, but **not** both.
## Snapshot Updates
The changes to the schema are visible in the snapshots updated in D24236505.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: fkgozali
Differential Revision: D24236510
fbshipit-source-id: bd344d67136418725d840e7332fd2f6957326bb4
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). ## Changes 1. Update the RN Codegen Component Parser 2. Update all RN Codegen Component Parser snapshots. Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236503 fbshipit-source-id: 975d97dd29bb5ca08e5de96e7814290c3dc4357b
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). ## Changes 1. Update the RN Codegen Module Parser 2. Update all RN Codegen Module Parser Jest tests & snapshots. Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236505 fbshipit-source-id: e24a39b4837c75a90fb4c957c56dfcf789511cc9
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236509 fbshipit-source-id: 1b603e8728d7be1e8bdede5878f57d6556b5c52f
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236502 fbshipit-source-id: 288c6d9588bde177732fe8165d3374eeacad999d
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236507 fbshipit-source-id: 2ffa0414db731a6ee844a2d1a5b07dc32bc763cb
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). ## Changes Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`. Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236508 fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236504 fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
Summary: NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack). ## Changes 1. NativeModule generators now use the new RN Codegen NativeModule schema. 2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`. 3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline. Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: PeteTheHeat Differential Revision: D24236405 fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary: Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: fkgozali Differential Revision: D24236813 fbshipit-source-id: 1fa573fade09914da673cd3750d78e4619ff4581
Summary: Adding support to the pointData to Android React Native Changelog: [internal] Reviewed By: swillard13 Differential Revision: D24256346 fbshipit-source-id: b970f771047cff580d9ebe7d6e2ad737394d6416
Summary: Adding support for boolean annotation in UserFlow API. Reviewed By: cdinh Differential Revision: D24337853 fbshipit-source-id: 52ed295c64a5650afbb02890f918939fb9d020d6
Summary: Changelog: [General][Added] - Adds the Hermes runtime bytecode version number to the JS bundle requestURL. This allows Metro with Bytecode to work with prebuilt binaries. Reviewed By: cpojer Differential Revision: D24327852 fbshipit-source-id: e8ee8db4f9b01f0500ab9dd851b5818c4adf3303
Summary: Fabric has a feature that preallocates views before mounting even need them. We never tested the impact of this feature thought. This diff adds a way to enable/disable it and run an experiment. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D24355612 fbshipit-source-id: fefd653e57232044cd7b28b160e12a4ef85dbb8b
Summary: The manual lookup logic was needed before we properly parse the module names from the spec js files. This is no longer necessary after the commit stack starting with facebook@3a75b37 Changelog: [Internal] Reviewed By: RSNara Differential Revision: D24370567 fbshipit-source-id: fc307d93cdda240a977e37dfe602502bd3f7c2a4
Summary: Some existing NativeModules have either Android or IOS suffix to denote the exclusive intent for that platform. For now, note this in the codegen schema output, so that the generator can skip irrelevant modules. Long term, each Flow type for module Spec should denote the intended/excluded platforms directly. Changelog: [Internal] Reviewed By: RSNara Differential Revision: D24370568 fbshipit-source-id: 8f725bdb39107d73c1aba0689db7f47ed7c374b0
Summary: If a native module schema has `excludedPlatforms` defined, honor it and skip the module that doesn't belong to the platform. E.g. NativeImagePickerIOS shouldn't generate anything for Android codegen output. Similarly, IntentAndroid shouldn't generate anything for iOS codegen output. Changelog: [Internal] Reviewed By: RSNara Differential Revision: D24373092 fbshipit-source-id: cfeb455a18c92f60191d988af2e9ce7ea5021304
Summary: The NativeModules spec parser uses `moduleName` to refer to the name of the NativeModule spec. This is confusing, because the NativeModules spec also has a `moduleNames` array, which refers to names of the NativeModules that get required in the spec. This diff renames `moduleName` to `hasteModuleName` within the NativeModule spec parser. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24386279 fbshipit-source-id: 8e4eb8dfc647241bf2bdae54dc8d9ab0122f49f9
Summary: Changelog: [Internal] Reviewed By: dsainati1 Differential Revision: D24364950 fbshipit-source-id: 42a81b155d803c3580cfac7d56c98f93a310d0fc
Summary: #changelog: [internal] When I built ThreadStorage I didn't know about existence of `thread_local` keyword. Because it achieves the same goal, using built in c++ features is preferred over building our own. Reviewed By: JoshuaGross, shergin Differential Revision: D24380680 fbshipit-source-id: e961fc34c6d3f085fc9b918b20bb4827de0d5624
Summary: Fixed URL of ChainReactConf website on the ECOSYSTEM.md ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Internal] [Fixed] - Fix URL of ChainReactConf Website Pull Request resolved: facebook#30199 Test Plan: URL leads to the ChainReactConf website Reviewed By: makovkastar Differential Revision: D24386708 Pulled By: cpojer fbshipit-source-id: 27a48e84547ef3bc067845b3c302dd57decc34b2
…e classes Summary: I've had my eyes on this optimization for a while: during TTRC especially, but really during any heavy render path, Fabric will create hundreds to thousands of MountItem class instances in order to construct a BatchMountItem. This results in: hundreds/thousands of round-trip JNI calls, hundreds/thousands of Object allocations, etc. This will also result in increased memory and GC pressure. Theoretically, by reducing the number of JNI calls and reducing allocations, we may be able to get some small wins in memory and CPU usage during very hot paths. I am motivated to do this, in part, to indirectly measure the cost of JNI calls as well as allocating many objects vs an int buffer. I am unaware of such a measurement that we can use to make architectural decisions for React Native Android overall. The other reason this could be a positive change: if it's successful and we can delete the old path, we'll be able to delete a bunch of Java classes entirely which is great for APK size wins. Changelog: [Internal] Reviewed By: shergin Differential Revision: D24631230 fbshipit-source-id: 86a46ffcaef4ecbec2e608ed226aed0b5c4b832e
Summary: For over a month I've been searching for a crash that occurs during Android's native `dispatchDraw` method on View. The stack traces didn't show anything useful - everything in the stack trace was native Android code, not React Native code. This also seems to only repro on certain vendors, and only on a very few React Native screens - I'm still not sure why either of those are the case, but from my repro, a *very* specific set of interactions needs to happen to trigger this crash. See comments inline and an example stack trace. Luckily, the fix is trivial. Since this code is used for animations, accessibility, and a number of other important interactions, I'm gating this change for now. In general we must be careful to only mutate the View hierarchy only when we /know/ for certain it is safe to do so. Indirectly mutating the View hierarchy during measure, onMeasure, layout, dispatchDraw, etc, can all be very dangerous. This is one of the last "escape hatches" that can cause view hierarchy modifications unexpectedly, so I think it's a very good idea to "secure" this further, and only update props synchronously here - and ensure that other MountItems like `Delete` are definitely /not/ executed here. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D24639793 fbshipit-source-id: b6219ce882e8d2204b4d10bf99f6a1120a33cb5a
Summary: Pull Request resolved: facebook#30250 Upgrade the version of Xcode used in Circle CI to Xcode 12.1.0, and target iOS 14.1 in tests. Reference: * Circle CI Xcode 12.1 container manifest (new version): https://circle-macos-docs.s3.amazonaws.com/image-manifest/v3985/index.html * Circle CI Xcode 11.6.0 container manifest (previous version): https://circle-macos-docs.s3.amazonaws.com/image-manifest/v3299/index.html > Source: https://circleci.com/docs/2.0/testing-ios/#supported-xcode-versions The default version of CocoaPods used in the Xcode 12.1 container image has changed. Use `bundle exec` with `pod install` to ensure we use the same version of CocoaPods as prescribed in the Gemfile. Changelog: [iOS][Changed] - Update iOS project template for Xcode 12.1.0 [iOS][Changed] - Bump CocoaPods 1.10.0 [Internal] Bump Xcode version used for iOS tests. Reviewed By: fkgozali Differential Revision: D24545010 fbshipit-source-id: 4a39781352bc5a85dae55ed5cd4e1ed6043a4aeb
Summary: Pull Request resolved: facebook#30265 The CocoaPods Specs mirror provided by Circle CI is no longer supported, and is no longer necessary, as of CocoaPods v1.8. We are already using the CDN in the Podfile, so the step may be removed from the Circle CI config. Reference: https://circleci.com/docs/2.0/testing-ios/#optimizing-cocoapods Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D24601585 fbshipit-source-id: c794102cf573e0cf47ae936bf3c1eb386e089315
Summary: Pull Request resolved: facebook#30279 Take in the fix from facebook#30273 + force starting adb server before launching AVD. Changelog: [Internal] Reviewed By: RSNara Differential Revision: D24638504 fbshipit-source-id: 7a379eb1db49ab418d9d91d20b49a02bbc0bc71c
Summary: Pull Request resolved: facebook#30280 Now that React Native targets minimum SDK of 21, use that SDK level to run test. For some reason the default was previously 16 (I couldn't figure out where this was configured). This fixes the following test failure: https://app.circleci.com/pipelines/github/facebook/react-native/6937/workflows/d2d365f8-3f5d-453d-af28-68a040fb4188/jobs/174719/parallel-runs/0 To test, using local Docker image: ``` root@d5618d33a37b:/app# buck test ReactAndroid/src/test/... Not using buckd because watchman isn't installed. Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 Parsing buck files: finished in 2.4 sec Creating action graph: finished in 0.6 sec Building: finished in 36.8 sec (100%) 577/577 jobs, 241 updated Total time: 39.9 sec Testing: finished in 02:19.7 min (167 PASS/0 FAIL) RESULTS FOR //ReactAndroid/src/test/java/com/facebook/react/animated:animated //ReactAndroid/src/test/java/com/facebook/react/bridge:bridge //ReactAndroid/src/test/java/com/facebook/react/devsupport:devsupport //ReactAndroid/src/test/java/com/facebook/react/modules:modules //ReactAndroid/src/test/java/com/facebook/react/packagerconnection:packagerconnection //ReactAndroid/src/test/java/com/facebook/react/uimanager/layoutanimation:layoutanimation //ReactAndroid/src/test/java/com/facebook/react/uimanager:uimanager //ReactAndroid/src/test/java/com/facebook/react/util:util //ReactAndroid/src/test/java/com/facebook/react/views:views //ReactAndroid/src/test/java/com/facebook/react:react PASS 18.3s 7 Passed 0 Skipped 0 Failed com.facebook.react.animated.NativeAnimatedInterpolationTest PASS 32.4s 24 Passed 0 Skipped 0 Failed com.facebook.react.animated.NativeAnimatedNodeTraversalTest PASS 25.2s 4 Passed 0 Skipped 0 Failed com.facebook.react.bridge.BaseJavaModuleTest PASS 1.8s 4 Passed 0 Skipped 0 Failed com.facebook.react.bridge.FallbackJSBundleLoaderTest PASS <100ms 1 Passed 0 Skipped 0 Failed com.facebook.react.bridge.JavaOnlyArrayTest PASS <100ms 2 Passed 0 Skipped 0 Failed com.facebook.react.bridge.JavaScriptModuleRegistryTest PASS 24.7s 10 Passed 0 Skipped 0 Failed com.facebook.react.devsupport.JSDebuggerWebSocketClientTest PASS 16.6s 4 Passed 0 Skipped 0 Failed com.facebook.react.devsupport.MultipartStreamReaderTest PASS 15.4s 5 Passed 0 Skipped 0 Failed com.facebook.react.devsupport.StackTraceHelperTest PASS 26.0s 6 Passed 0 Skipped 0 Failed com.facebook.react.modules.blob.BlobModuleTest PASS 21.6s 5 Passed 0 Skipped 0 Failed com.facebook.react.modules.camera.ImageStoreManagerTest PASS 15.1s 1 Passed 0 Skipped 0 Failed com.facebook.react.modules.clipboard.ClipboardModuleTest PASS 14.4s 5 Passed 0 Skipped 0 Failed com.facebook.react.modules.dialog.DialogModuleTest PASS <100ms 10 Passed 0 Skipped 0 Failed com.facebook.react.modules.network.HeaderUtilTest PASS 7.9s 14 Passed 0 Skipped 0 Failed com.facebook.react.modules.network.NetworkingModuleTest PASS 4.3s 9 Passed 0 Skipped 0 Failed com.facebook.react.modules.network.ProgressiveStringDecoderTest PASS 5.2s 4 Passed 0 Skipped 0 Failed com.facebook.react.modules.network.ReactCookieJarContainerTest PASS 9.0s 2 Passed 0 Skipped 0 Failed com.facebook.react.modules.share.ShareModuleTest PASS 9.3s 6 Passed 0 Skipped 0 Failed com.facebook.react.modules.storage.AsyncStorageModuleTest PASS 6.7s 10 Passed 0 Skipped 0 Failed com.facebook.react.modules.timing.TimingModuleTest PASS 22.2s 9 Passed 0 Skipped 0 Failed com.facebook.react.packagerconnection.JSPackagerClientTest PASS 18.3s 4 Passed 0 Skipped 0 Failed com.facebook.react.uimanager.layoutanimation.InterpolatorTypeTest PASS 16.9s 2 Passed 0 Skipped 0 Failed com.facebook.react.uimanager.BaseViewManagerTest PASS 15.9s 4 Passed 0 Skipped 0 Failed com.facebook.react.uimanager.MatrixMathHelperTest PASS 16.8s 3 Passed 0 Skipped 0 Failed com.facebook.react.uimanager.SimpleViewPropertyTest PASS <100ms 1 Passed 0 Skipped 0 Failed com.facebook.react.util.JSStackTraceTest PASS 19.9s 1 Passed 0 Skipped 0 Failed com.facebook.react.views.image.ImageResizeModeTest PASS 21.5s 4 Passed 0 Skipped 0 Failed com.facebook.react.views.image.ReactImagePropertyTest PASS 22.9s 4 Passed 0 Skipped 0 Failed com.facebook.react.CompositeReactPackageTest PASS 15.9s 2 Passed 0 Skipped 0 Failed com.facebook.react.RootViewTest Updated test logs: buck-out/log/test.log TESTS PASSED ``` Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20. Reviewed By: JoshuaGross Differential Revision: D24643610 fbshipit-source-id: 0b9536076d08019ef154b338acd136a82cc5a166
Summary: Historically, `UIScrollView`s in React Native do not cancel touches started on `UIControl`-based views (as normal iOS `UIScrollView`s do). This diff implements this behavior. Changelog: [Internal] Fabric-specific internal change. Reviewed By: JoshuaGross Differential Revision: D24661106 fbshipit-source-id: 1fb98d62f9e1528f11e7699d460aaefcec534e97
Reviewed By: zertosh Differential Revision: D24679750 fbshipit-source-id: 42d5a8aa40ec99be9a51a8e3eed54f2fc8e29e3a
Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes facebook#27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes facebook#28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported facebook#27845 and facebook#28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: facebook#29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
Summary: Fix broken links in README by removing `.html` from any `reactnative.dev/docs` ## Changelog General Fixed - Fixed broken links in README.md <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> Pull Request resolved: facebook#30286 Reviewed By: hramos Differential Revision: D24673358 Pulled By: cpojer fbshipit-source-id: 726a4742c3ae19dc51f2490619d04934f8aa861d
… animations without a final Mutation already queued up Summary: For some interrupted animations we will execute a "final" mutation associated with the animation, if it exists. For example, "UPDATE" animations always have a final Update animation associated with them. Some, however, do not. For example: INSERT animations do not have a final mutation associated by default. In these cases (before this diff) if the animation from opacity 0 to 1 was interrupted, the View will appear "stuck" at some intermediate opacity. To mitigate that, we generate a synthetic "final" mutation at 100% progress through the animation if it is interrupted. Changelog: [Internal] Reviewed By: fred2028 Differential Revision: D24691151 fbshipit-source-id: d9730b8a3493a5eeac4de325e7e0a7a64f73c8a0
Summary: docker-android released v2 which reduced image size. ## Changelog [Internal] [Changed] - bump docker-android to 2.1 Pull Request resolved: facebook#30296 Test Plan: test_android, test_docker is green Reviewed By: fkgozali Differential Revision: D24686168 Pulled By: hramos fbshipit-source-id: c240848f10f473b38a0967dd681254c21f877277
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
We noticed that after applying d03c0f9, `pod install` complains when we try to autogenerate FBReactNativeSpec.h and FBReactNativeSpec-generated.mm because some of our TurboModule specs aren't completely compatible with codegen. This commit fixes this issue, updates FBReactNativeSpec files, and fixes any resulting compiler issues in native macOS/iOS code. Validated that ActionSheet, Alert, and Switch still work in RNTester for both macOS and iOS.
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
HeyImChris
approved these changes
Oct 7, 2021
This moves FBReactNativeSpec generation into Xcode's build process. Although this made it in before 0.64.0, we're bringing it in now because it keeps our CI for creating a new project from scratch intact.
…0449) Summary: Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod. This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed. The codegen will thus be invoked in these situations: **RNTester:** * When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed. **OSS React Native apps:** * When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`. Pull Request resolved: facebook#30449 Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod Reviewed By: fkgozali Differential Revision: D25138896 fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary: The wrong value for the path to react-native-codegen was being used. The issue was introduced during the refactoring of this script for use in FBReactNativeSpec.podspec. Changelog: [Internal] Motivation: Reviewed By: fkgozali Differential Revision: D25290355 fbshipit-source-id: 5a46c680e7ea41157b03cf54a640a8816fb682b3
Summary: Quick fix for Circle CI: Ensure FBReactNativeSpec dir exists before touching files. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D25285573 fbshipit-source-id: 8dec496856c90accc687648d7068aadfea24d72b
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary
Merge facebook/react-native's main branch into react-native-macos's main branch through 2020-11-03 23:59:59 PDT (specifically, 9500eb8).
Notably, this commit is also the result of running
git merge-base facebook/main facebook/0.64-stable. In other words, after this commit, we can officially create a 0.64-stable branch in react-native-macos and start working towards 0.64 release candidates and official releases.These changes were made by repeatedly running git merge and resolving merge conflicts as needed.
Notes
56c363e requires adding an extra macOS check in Libraries/Linking/Linking.js.
We are now required to use Node 12 or greater, as dictated by 4b92e2e. In addition, 5a73af6 introduces the use of
Array.flatMap, which is only available in Node 11 or greater.With d03c0f9, we are now generating FBReactNativeSpec.h and FBReactNativeSpec-generated.mm on the fly using codegen. This is involved enough that it deserves its own section.
Notes on Codegen
The main consequence of using codegen is that we need to be a bit stricter with what types are allowed in TurboModules (for example, we can't have fancy union types because they don't translate well into a native type). As a result, we had to make changes in these files (see b4d0a57) to accommodate:
I validated that ActionSheet, Alert, and Switch still work in RNTester, so I believe that we should be okay here.
NativeAlertManager.js now uses a modified native version that codegen will like. I'm not entirely thrilled about the looseness of
defaultInputs?: Array<Object>, but it seems to be the right thing to do based on what codegen spits out. Previously, our manually adjusted FBReactNativeSpec.h considereddefaultInputsas afolly::Optional<facebook::react::LazyVector<id<NSObject>>>, and the new autogenerated FBReactNativeSpec.h keeps this type the same.The other three files get rid of
ProcessedColorValueas an option for colors in various files. This gets rid of some divergence and lines up with upstream 0.64-stable whenever possible. I don't know if this will break anything in the future, so clients should be careful when adopting the next version.Note that b4d0a57 still uses a premade FBReactNativeSpec files, although the manual adjustments came from running the appropriate codegen commands. Starting in 9218e0c, we delete the premade versions and start wholly depending on codegen to construct these files for us.
Validation