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/37274
With dynamic frameworks, we can't use floating C functions.
The way in which dynamic frameworks work is that they need to be self contained. They are built in isolation so that other frameworks can be linked against them to solve their dependencies.
Currently, when working with 3rd party libraries, we are Codegenerating a RCTThirdPartyComponentProvider which tries to invoke floating C functions that are defined in other modules. React-RCTFabric has no visibility on those modules, therefore it fails building.
The implemented solution exclude the generation of those symbols and leverage a the Objective-C runtime to automatically register libraries when they are loaded.
**This mechanism is applied ONLY when the flag RCT_DYNAMIC_FRAMEWORKS is turned on.** There will be no impact on internal meta apps, nor on any apps that are not using Dynamic Frameworks.
This change requires a small migration in all the Fabric components libraries that wants to support dynamic frameworks. They have to implement a
```
+ (void)load
{
[super load];
}
```
method in their ComponentView.
Not to slow down the adoption of the new architecture, waiting for a migration in the ecosystem, the next diff introduce a secondary, declarative loading mechanism for Fabric Components, which follows the same approach used by TurboModules.
## Changelog:
[iOS][Changed] - Add support for distributed registration of Fabric Components with Dynamic Libraries.
Notes that this change is NOT breaking as dynamic frameworks were not working before in the New Architecture. Static Libraries and Static Frameworks continue working as usual.
Reviewed By: dmytrorykun
Differential Revision: D45605441
fbshipit-source-id: e609fbf6f92fddfbaa676227fde60962d6b0faa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37145
This diff adds the generation of Array types in events.
It supports the generation of Array of:
- Boolean
- Int32
- Float
- Double
- String
- Objects
- Array
**Note:** This is a first iteration. We could improve the generation further by leveraging the `Bridging` module within React Native.
I'll take a stab at it in a next diff.
## Changelog:
[General][Added] - Generate events with arrays
Reviewed By: cortinico
Differential Revision: D45321685
fbshipit-source-id: 34b05f5501b06714d1fabf1a51cb057af7027f00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37085
changelog: [internal]
Props and event emitter does not need to use JSI_EXPORT. Therefore we can remove include of jsi.h as well.
Reviewed By: cortinico, rshest
Differential Revision: D45274824
fbshipit-source-id: dd756258767f787e49d86dc31e18ce581f444362
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/36591
If any of the properties used in event-emitter codegen conflict with `event` or `payload`, the generated code will fail to build, even if this generated code isn't used. Since these are quite common keys, prefix them with `$` (still valid C++) to avoid conflicts.
Changelog: [General][Fixed] Resolved property name conflicts in event-emitter codegen
Reviewed By: cipolleschi
Differential Revision: D44274619
fbshipit-source-id: 45e67850c49e082d8f9b1f85bb632d45a9fd4f1d
Summary:
- Add .d.ts files for generators
- export each generators because `react-native-windows` need its own selection of generators.
## Changelog
[GENERAL] [CHANGED] - Add minimum necessary .d.ts files to react-native-codegen (2)
Pull Request resolved: https://github.com/facebook/react-native/pull/36397
Test Plan:
`npm run build` in `packages/react-native-codegen` and see all .d.ts files appear in `lib`.
Checked .d.ts file in typescript playground.
Reviewed By: rshest
Differential Revision: D43941811
Pulled By: cipolleschi
fbshipit-source-id: 28f5bd56f27531ecf25223620a580358018b779d
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Changelog:
[Internal][Added] - Add support for props of type Array<EdgeInsetsValue>
Reviewed By: christophpurrer
Differential Revision: D42651078
fbshipit-source-id: 3b8683ab199c3d590136cec0e6a67e9e85aaa2c0
Summary:
Changelog: [Internal]
While working on implementing [Event Timing API](https://www.w3.org/TR/event-timing/) I've noticed that there are multiple compiler warnings about unused lambda captures, which are coming from generated C++ code for EventEmitters.
This modifies the codegen so that the corresponding lambda doesn't capture event variable if it's not used in the event handler, thus getting rid of warnings.
Reviewed By: christophpurrer
Differential Revision: D42281899
fbshipit-source-id: 98442bb9f3ce374755188d818a9b2d6a8050bf15
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:
This diff adds type parameters to all uses of `new Array`.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D41746116
fbshipit-source-id: 8aa2777dd13ef4cd9f8613adaa3509d3573d4446
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:
i recently made a change to modularize some of our graphics dependencies
i think this codegen will be incorrect now after my diff, so i updated it so we would codegen the correct deps
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D41451842
fbshipit-source-id: 98b5576e9fbd2d693c8bcfeac39d8dfb1b1e0584
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 is the second diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog:
[General][Removed] - Back out parsing and generation of Custom Native State from Codegen
Reviewed By: cortinico
Differential Revision: D40426134
fbshipit-source-id: c368e122cc31ee8df056fe1bf6cecaab482140a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34910
This Diff adds supports on the CustomState generation for ImageSource and ImageRequests, to enable NativeComponents to use the ImageSource loading provided by React Native.
To achieve this, I also had to fox some errors in the imports and to introduce some functions to decorate parameters.
This diff also introduces the tests for thise additional types in both generators and parsers.
## Changelog
[General][Added] - add support for ImageSource and ImageRequest in the State.
Reviewed By: cortinico
Differential Revision: D39884889
fbshipit-source-id: ae3d2d51dfe6a4fe688dc78fec83f428beb8d443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34796
This diff introduces the generation of custom native states using basic types as we do with the Props.
To make it work, the custom types are already writte in the Props.h file, therefore the State.h file must import that other file to have access to the required types.
This diff adds and updates the tests for the State.
## Changelog
[General][Added] - Generate custom Native State
Reviewed By: cortinico
Differential Revision: D39816763
fbshipit-source-id: 42d1aa9a6df23145f4a46ae8ccfb43d81fa651fb
David Vacca
Sunbreak
Samuel Susla
Nick Gerleman
Ruslan Shestopalyuk
Roy Berger
Nicola Corti
Sam Zhou
Christoph Purrer
Riccardo Cipolleschi
Genki Kondo
Phillip Pan
Pieter De Baets
Zihan Chen (MSFT)
Vitali Zaidman
Mikhail Mikhaylov
Luna Wei
Mike Vitousek
Ruslan Lesiutin
Jordan Brown