Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41771
Changelog: [Internal]
Since we are already enforcing C++20 (and 17), we can set the namespace declaration to the C++17 style
Reviewed By: NickGerleman
Differential Revision: D51789991
fbshipit-source-id: 165d7d4e652d60ab200e2355e084010a02f470a4
Summary:
Handling of `EnumDeclaration` was introduced in D38967241 (https://github.com/facebook/react-native/commit/745f3ee8c571560406629bc7af3cf4914ef1b211) so it is no longer a type expected to fail generators.
Changelog: [Internal] remove 'EnumDeclaration' as a type expected to throw error in module generators
Reviewed By: cipolleschi
Differential Revision: D42917947
fbshipit-source-id: 16fcb915ccd42c613ca4d30b815d6365681f5fa1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36042
Pull Request resolved: https://github.com/facebook/react-native/pull/36028
Use aliasMap both in parsers and generators instead of using aliasMap in half of the places and aliases in the other.
This would also allow us to introduce "enumMap" more easily in the next commit.
Changelog: [Internal] rename module exports from "aliases" to "aliasMap"
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42888752
fbshipit-source-id: cf1929fcebde994d07e5c6bda5ab71106d417b21
Summary:
We have the expected module name available as part of the codegen schema, so we can remove the need for developers to implement the `getName` method as part of their module implementation.
Note that this method is not actually used when the TurboModules infra is used, as the moduleName from the turbo module manager is passed through to the TurboModule base class instead. Moving the method to codegen will make it easier to remove this method altogether once the old architecture is fully removed.
Changelog: [Android][Added] Support generating `getName` in react-native-codegen for Java TurboModules
Reviewed By: mdvacca
Differential Revision: D41615387
fbshipit-source-id: 6b117645fa39e5e9ab014b21198496a52f6f2ae2
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872
_Extract the modules/utils.js from the flow and typescript folders in a shared parsers-commons.js file. Then, have the two parsers use the same wrapModuleSchema function for modules._
(`wrapModuleSchema` is a copy-paste mistake, in this case it is `wrapNullable` and `unwrapNullable`)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extracts Codegen's modules/utils.js files from the flow and typescript folders in parsers-commons
Pull Request resolved: https://github.com/facebook/react-native/pull/34898
Test Plan:
I ran `yarn jest react-native-codegen`:
<img width="775" alt="Capture d’écran 2022-10-07 à 21 29 48" src="https://user-images.githubusercontent.com/17070498/194639515-a446c2cf-daf3-43a1-9833-cd546ca5865e.png">
Reviewed By: cipolleschi
Differential Revision: D40193740
Pulled By: cipolleschi
fbshipit-source-id: 02cbacc215fe5dd9bdd0839d8796587ab2821906
Summary:
There are cases where we want to pass an enum type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```enum Quality { SD, HD, }```
Approach:
- We are not generating an ```enum``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed enum types at this time, e.g. ```export enum StringOption { One = 'one', Two = 2, Three = 'three', };``` will not work. See: https://www.typescriptlang.org/docs/handbook/enums.html#heterogeneous-enums
- We only support untyped (default to String), String, and Number enum properties
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Enum Type support for C++ TurboModules
Reviewed By: RSNara
Differential Revision: D38880963
fbshipit-source-id: f2399b29948306bc555429b6f96c43ea4c39c46e
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
There are cases where we want to pass arbitrary types to a TurboModule, which may then handle the values appropriately, but we haven't supported this use case. Since C++ TurboModules can accept any `jsi::Value` (unlike Java/ObjC) and we have real-world need for this (otherwise we must require JSON serialization), this now allows `mixed` (`unknown` in TypeScript) for C++-only TurboModules.
Changelog:
[General][Added] C++ TurboModule methods can now use mixed types
Reviewed By: RSNara
Differential Revision: D36611299
fbshipit-source-id: bbf29dfcc6aed67e213bb3eab06537c18c7db1fe
Summary:
Codegen a static field for every caller of `invokeJavaMethod` to cache the jmethodID that should be used for the method, which saves us a string-based name lookup at invocation time.
Changelog: [internal]
Reviewed By: genkikondo
Differential Revision: D36376056
fbshipit-source-id: 298430746a8f25a5337aba05b56876ba789e2344
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
## Changes
{| ... |} -> { ... }
**Motivation:** In Flow, object literals are exact by default. So, there's no need for the pipes. Also: Now, the syntax for object literals is consistent across react-native-codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24774771
fbshipit-source-id: 24ceb6f5876122aa8ad9e08c7e903215864ad6f5
Summary:
Everywhere else in the CodegenSchema, type annotation partials are suffixed with "Shape". In the NativeModule schema, we were using the suffix "Schema". In this diff, we standardize on the "Shape" suffix.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719395
fbshipit-source-id: 307935f5fe0681c31cd52e9cf4ae579f61c1ae68
Summary:
CodegenSchema exports `NativeModuleMethodParamSchema` and `NativeModuleObjectTypeAnnotationPropertySchema`, which are partials of NativeModule type annotations. This creates unnecessary coupling between the type annotations of CodegenSchema and the files that depend on it.
**Actual Problem:** Suppose that we want to rename one of these partials. Then, all imports in all files would have to be updated, even when the actual shape of the composed type annotation wasn't changed.
This diff removes these partials, which reduces the surface area of the exports of CodegenSchema.js
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719396
fbshipit-source-id: c822aaa252f156c524f4ef4917ebb61b1a39ff9e
Summary:
Reserved type annotations can appear in three different contexts: commands, props, and NativeModules. For now, commands and NativeModules share the same reserved type annotations. In the future, we may want to merge these reserved type annotations with the props reserved type annotations.
**Motivation:** The meaning of FunctionValue in FunctionValueTypeAnnotation isn't clear - in fact, it's downright confusing. Therefore, this diff renames this Flow type to ReservedTypeAnnotation, which I believe sufficiently captures the intent of the type annotation.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701322
fbshipit-source-id: bde0273b4a89c9e7175c60ed3468ed870b320044
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
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:
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:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23667253
fbshipit-source-id: ef94e75287d37dfd7b80f61455a1bfa34bddeb28
Summary:
We have first class support for Promises in our codegen. So, it's more appropriate to just call this PromiseTypeAnnotation, as opposed to GenericPromiseTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645209
fbshipit-source-id: bfc0b909750e221e18be33acf197f342a2918aa9
Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809082
fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d
Summary:
The TurboModule system requires a lookup function to map the spec name (name used in JS) to the C++ TurboModule subclass. This is a pure C function. For now, generate one lookup function per set of modules found in the codegen schema.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618281
fbshipit-source-id: 889e07bdd4f2e5e93c4d14e60225f5b0c6683917
Christoph Purrer
Moti Zilberman
Vitali Zaidman
Pieter De Baets
Antoine Doubovetzky
Christoph Purrer
Scott Kyle
Pieter De Baets
Nicola Corti
Andres Suarez
Tim Yung
Daniel Sainati
Erich Graham
Ramanpreet Nara
Kevin Gozali
