Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42122
This diff introduces the `TypeUtils` directory where we can put platform-specific, context-independent type transformations.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52291837
fbshipit-source-id: 561b9c494aab5bfee3b3c668d3346bbd320e5266
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41956
By default, generated Cxx sources for components all end up in same directory. However the include declarations in them look like this:
```
#include <react/renderer/components/${libraryName}/ShadowNodes.h>
```
And not like this:
```
#include "ShadowNodes.h"
```
This works fine with Buck because it supports header prefixes.
To get this working with CocoaPods we define additional `HEADER_SEARCH_PATHS` for our `React-Codegen` pod.
This approach will not work if we want to generate code at the library level and check in the artifacts. That's because we don't have control over the Podspec there, and can't inject those additional `HEADER_SEARCH_PATHS`.
This diff adds the `headerPrefix` argument to the codegen entry point. It is `react/renderer/components/${libraryName}` by default, but can become empty if we want to generate code at the library level, and don't want to deal with this nested header structure.
*Note:* `RNCodegen` runs all the generators [in a loop](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/generators/RNCodegen.js#L263-L275), assuming that the all have same function signature So I had to add the `headerPrefix` argument to all the generators, even to the ones that don't really need it.
Changelog: [General][Added] - Introduce "headerPrefix" codegen option.
Reviewed By: zeyap
Differential Revision: D51811596
fbshipit-source-id: c5c3e1e571c7c4ea2f5354eb9a7b0df6b917fc0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41923
Changelog: [Internal][BREAKING] Use C++ enum classes in C++ Turbo Modules
Problem:
Using **C styles** `enums` can easily cause compiliation errors if symbol names collide. This code does not compile:
```
enum CustomEnumInt { A = 23, B = 42 };
static int A = 22;
```
This **C++ code**, using `enum classes` compiles:
```
enum class CustomEnumInt : int32_t { A = 23, B = 42 };
static int A = 22;
```
Reviewed By: rshest
Differential Revision: D52098598
fbshipit-source-id: c919bd2e41970c83a032fec91b0537cd6fae8397
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/41645
Right now, when defining concrete structs and Bridging headers for Cxx TMs we need to define their member types twice:
```
using ConstantsStruct =
NativeCxxModuleExampleCxxBaseConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxBaseConstantsStructBridging<
bool,
int32_t,
std::string> {};
```
Now we only need to define those once
```
using ConstantsStruct =
NativeCxxModuleExampleCxxConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxConstantsStructBridging<ConstantsStruct> {};
```
This change keeps the existing base types untouched - but they will be removed in the next RN version.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51571453
fbshipit-source-id: 2783bd48bf786ffa80d322d06456b5d6f2d7ba8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39454
1. Build with C++ 20 everywhere.
2. Update folly in OSS build to avoid a warning, and let us opt out of heavy bits required for supporting coroutines (we are still more than a year behind).
3. Update the folly podspec for the new version of folly
4. Update the many, many, copy/pasted header search paths for folly dependencies to be able to resolve fmt, now exposed to folly headers
4. Replaces a deprecated atomic usage with equivalent.
5. Fixes a deprecated implicit capturing `this` by value in lambda (same behavior, added a TODO because it seems sus)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49271685
fbshipit-source-id: 16610f7bcd1032d5796cc11f1cfa92a33d8c2593
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39212
## Changelog:
[Internal] -
Some of the generated C++ code was badly formatted - even though it's normally not supposed to be read by humans, sometimes it's still useful/needed, so it helps when it's more readable.
Reviewed By: christophpurrer
Differential Revision: D48827010
fbshipit-source-id: 3481af68ee6158902007c431e72e631d852c8b3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39136
## Changelog:
[Internal] -
`getConstants()` method for TM was enforced to only use object literals for the return type specs.
This limits flexibility, in particular those data structures can't be consequently exported and picked up by codegen (not even mentioning the potential need for copypasting those obejct literals around).
This relaxes this restriction.
Note that I've been digging into the development history in order to find out whether there was any particular historical reason for such a limitation, but couldn't find any, so I assume it was rather incidental.
Reviewed By: christophpurrer
Differential Revision: D48620652
fbshipit-source-id: 92d6ba531fc99fb9b25b4957ae123e7832f44ee4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38295
Move constant to class instance so customers can use strongly typed name, feedback from D46159001
Changelog:
[Internal] [Changed] - Add module name constant to codegen'd class for downstream use
Reviewed By: christophpurrer
Differential Revision: D47095993
fbshipit-source-id: 741d0d837bf912d6b32e5f12c5df871563d46686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37832
This parameter is currently unused and is causing Android builds to fail
as they compile with `-Wall`
This is a follow-up to https://github.com/facebook/react-native/pull/37454/ as that PR updated only the `fromJs` and not the `toJs` method as well.
Changelog:
[Internal] [Changed] - Remove CallInvoker parameter from toJs method in Codegen
Reviewed By: rshest
Differential Revision: D46647110
fbshipit-source-id: 1f3e22aca7a3df11ac02b5c4b89c9311b8b1798c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36673
Changelog: [Android][Deprecated]
in this change, we deprecate ReactModuleWithSpec because it can be replaced with the TurboModule interface which better describes our generated modules.
Reviewed By: cortinico
Differential Revision: D44450959
fbshipit-source-id: adab192593843926f35bdbeb346ef374dd80e615
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36030
Generate enum types in c++ turbo modules.
For enums in the ts schema file such as:
```
export enum NumEnum {
ONE = 1,
TWO = 2,
}
```
This would export enums and the relevant Bridging to js and from js code to the spec H files such as:
```
#pragma mark - SampleTurboModuleCxxNumEnum
enum SampleTurboModuleCxxNumEnum { ONE, TWO };
template <>
struct Bridging<SampleTurboModuleCxxNumEnum> {
static SampleTurboModuleCxxNumEnum fromJs(jsi::Runtime &rt, int32_t value) {
if (value == 1) {
return SampleTurboModuleCxxNumEnum::ONE;
} else if (value == 2) {
return SampleTurboModuleCxxNumEnum::TWO;
} else {
throw jsi::JSError(rt, "No appropriate enum member found for value");
}
}
static jsi::Value toJs(jsi::Runtime &rt, SampleTurboModuleCxxNumEnum value) {
if (value == SampleTurboModuleCxxNumEnum::ONE) {
return bridging::toJs(rt, 1);
} else if (value == SampleTurboModuleCxxNumEnum::TWO) {
return bridging::toJs(rt, 2);
} else {
throw jsi::JSError(rt, "No appropriate enum member found for enum value");
}
}
};
```
That code would allow us to use these enums in the cxx files like this:
```
NativeCxxModuleExampleCxxEnumInt getNumEnum(
jsi::Runtime &rt,
NativeCxxModuleExampleCxxEnumInt arg);
```
Changelog: [General] [Added] Generate enum types that would be allowed to be used as well as string/number in c++ turbo modules generators
Reviewed By: christophpurrer
Differential Revision: D42884147
fbshipit-source-id: d34d1fc7ba268b570821dc108444196f69a431b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36044
> **Notice**: This commit does not change any behaviour.
Parse and collect enum members in module specs instead of the current behaviour of parsing enum members as 'string' / 'number' and ignoring the member names.
This commit would allow us to generate native Enums corresponding to the schema's enums.
Prior to this commit, enum params were parsed as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
The name of the enum type and the members of the enum type were ignored.
After this commit, parsed modules would hold a new object member called `enumMap` that would look like this:
```
'enumMap': {
'QualityEnum': {
'name': 'QualityEnum',
'type': 'EnumDeclarationWithMembers',
'memberType': 'StringTypeAnnotation',
'members': [
{
'name': 'SD',
'value': 'sd'
},
{
'name': 'HD',
'value': 'hd'
}
]
},
// ...
}
```
And enum params would be exported as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'name': 'NativeModuleEnumTypeAnnotation',
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
Combining the two new outputs would allow us to generate Native enums in the Native generators.
Changelog: [Internal] Parse and collect enum members in turbo module specs
Reviewed By: cipolleschi
Differential Revision: D42778258
fbshipit-source-id: 56479342e085bc4e13c5a3e12b265b140e49893c
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:
While working on D42008409 I found out that codegen for pure C++ modules doesn't work with container types that are nested inside generated data structures, which happens because they don't have a specialization of `bridging::toJS` that wouldn't pass the `invoker` instance through.
It looks like an easiest option would be just to use `invoker` in codegen for `toJS` as well, which this diff does.
Note that I also experimented with removing `invoker` from being used in the `::toJS` specializations for containers altogether (see D42008410), as there doesn't seem to be a single use case when `invoker` would be ever needed in any `::toJS` specialization (and imagining such a scenario would be a stretch, tbh - why a conversion function would invoke anything running on JS side, given that invoker provides no return values anyway?..)
But since I am still not 100% about the invoker purpose there, I went with the codegen change.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008724
fbshipit-source-id: 6302d3ceacdfc8fed296ee1ef1a985f7273c2261
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35540
We now don't need to generate .mk files anymore, therefore I'm removing
this logic from the codegen. In RN 0.72 users should be fully migrated
to CMake.
Changelog:
[Android] [Removed] - Remove .mk prebuilt file and .mk file generation from codegen
Reviewed By: rshest
Differential Revision: D41654122
fbshipit-source-id: 3a3c01fa8ab4d48460338e1a9ce2ecbd6df25f47
Summary:
Noticed these types could be improved based on the tests added in D40979066 (https://github.com/facebook/react-native/commit/e81c98c842380d8b72c1dc8d4a6e64f760e2a58c).
Changelog: [Android][Fixed] Corrected Nullable annotations for parameters and return values in TurboModules codegen
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40979940
fbshipit-source-id: cfc352a9e7eb9f59e2cce3d7da110a9a8d32db4b
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
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:
This change will expose the rrc_image module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose rrc_image to consuming build
Reviewed By: cipolleschi
Differential Revision: D40098541
fbshipit-source-id: 2e07d8b19f53ba93920009603c95a43b01f131eb
Summary:
This change will expose the `react_render_imagemanager` module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose react_render_imagemanager to consuming build
Reviewed By: cipolleschi
Differential Revision: D40022929
fbshipit-source-id: ece47503b11a641067ae6db82f1d69b244c9c5be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
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:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`.
Changelog:
Internal
Reviewed By: javache
Differential Revision: D36989312
fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
This fixes an issue where nullability was lost on readonly types in TurboModules specs. The "outside" nullability would be ignored in favor of only respecting the "inside" nullability (i.e. `?$ReadOnly<{}>` vs `$ReadOnly<?{}>`). It now ensure either is propagated correctly.
Changelog:
[General][Fixed] Fix nullability lost on readonly types in TurboModule specs
Reviewed By: RSNara
Differential Revision: D36615346
fbshipit-source-id: 42408d9298703f4c382657f573480d2574d6c973
Dmitry Rykun
Christoph Purrer
Moti Zilberman
David Vacca
Sunbreak
Nick Gerleman
Ruslan Shestopalyuk
Roy Berger
Nicola Corti
Phillip Pan
Pieter De Baets
Vitali Zaidman
Ruslan Lesiutin
Mike Vitousek
Jordan Brown
Antoine Doubovetzky
Riccardo Cipolleschi
Rujin Cao
Christoph Purrer
Tim Yung
Pieter Vanderwerff
Scott Kyle
Nicola Corti
