Summary:
Adjust generated ObjC++ code to resolve a few build time and run time errors:
* Suppress CONSTANTS struct implementations
* Use type alias name as struct name when serializing arguments that involve a type alias
* Use actual number of arguments for a method when generating method map.
With these changes in place, RNTester can be built and run using the code that is generated by the new codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23926500
fbshipit-source-id: 88fcbb795fd71dc8155eb26348db943975e13e84
Summary:
* Removed extraneous closing brace.
* Fixed static method signature, replacing double colon with an underscore (`static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI::${methodName}()` -> `static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI_${methodName}()`).
* Wrap `getConstants` selector name with `selector()`.
* Pass through `getConstants` and `constantsToExport` to allow de-duping of `getConstants` method in generator output.
Note that the FBReactNativeSpec that is output by the generator still has some issues that need to be addressed before it can be used.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23910505
fbshipit-source-id: 37d884885b8878f38d40637377c2a74a728c3a13
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:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667250
fbshipit-source-id: f36b5418101c40331964d1f9ede7c6bd7924383d
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667255
fbshipit-source-id: 40b7747aad89f6d5bbb9f42d59a4df9633060c66
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667252
fbshipit-source-id: 34404a478ddd67446d82b5f98e1051300064e95c
Summary:
Just updating this generator to understand the new RN Codegen Module parser flow types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667254
fbshipit-source-id: 558dd7ac5b4541edf40248b8ab8bb50d31fa8624
Summary:
## Misc. Improvements
* We now have 95%+ flow coverage in all generator files. Henceforth, we can make changes to these files with more confidence, and trust flow to catch more errors. This should also improve the DevX of working on these files.
* Better templates: Instead of doing string replace with RegExps, we instead use functions and leverage JS template literals to generate our code. A few benefits: (1) data dependencies of templates are clearly visible, and statically checked by flow, (2) the templates are more readable in VSCode.
* Merged the GenerateModuleHObjCpp.js and GenerateModuleMm.js generators. They can share a lot of logic, so it's not a good idea to keep them separate.
* The ObjC++ module generator no longer generates “dead” structs (i.e structs that aren’t used by type-safety infra). In fact, it explicitly only supports the types in our Wiki. (I know this wasn’t the case with the legacy codegen, because we were generating native code for enums in the legacy codegen). This is a mixed bag. The test to verify correctness will be more difficult to write. However, keeping structs in the codegen needlessly complicates the parsers + generators, and creates technical debt for us to clean up later.
## Abstractions
- **StructCollector:** As we serialize NativeModule methods, when we detect an ObjectTypeAnnotation in the return type of `getConstants()` or inside a method param, we must create a Struct JS object for it. When we detect a type-alias (also in the same locations), we must look up that type-alias and create a Struct from its RHS. A Struct is basically an ObjectTypeAnnotation with a context (i.e: used in getConstants() vs as a method param), that cannot contain other ObjectTypeAnnotations.
- **serializeMethod.js** Given a NativeModule method type annotation, output the protocol method, JS return type, selector, a record of which params were structs, and which structs. Basically, this is all the information necessary to generate the declaration and implementation codegen for a partiular NativeModule method.
- **serializeStruct/*.js**: After creating all these Structs, we need to loop over all of them, and tranform them into ObjC++ code.
- **serializeStruct.js**: Depending on the struct context, calls either `serializeRegularStruct.js` or `serializeConstantsStruct.js`. Both of these files have the same layout/abstractions. They look very similar.
- **serializeModule.js:** Outputs RCTCxxConvert categories for transforming `NSDictionary *` into C++ structs. Outputs ObjCTurboModule subclass.
## Algorithm
```
for spec in NativeModuleSpecs
structCollector = new StructCollector
resolveAlias = (aliasName) => nullthrows(spec.aliases[aliasName])
methodDatas = []
for method in methods(spec)
methodData.push(serializeMethod(method, structCollector, resolveAlias))
end
structs = structCollector.getStructs()
output generateImplCodegen(methodDatas, structs)
output generateHeaderCodegen(methodDatas, structs)
end
```
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23633940
fbshipit-source-id: 7c29f458b65434f4865ef1993061b0f0dc7d04ce
Summary:
There are two operations we do in every NativeModule generator:
- We convert the `SchemaType` into a map of NativeModule schemas
- If the type-annotation is a TypeAliasTypeAnnotation, we resolve it by doing a lookup on the NativeModuleAliasMap. This is usually followed by an invariant to assert that the lookup didn't fail.
Both procedures have been translated into utilities for use across our generators. I also deleted `getTypeAliasTypeAnnotation` which will no longer be used.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667249
fbshipit-source-id: 4e34078980e2caa4daed77c38b1168bfc161c31c
Summary:
In diffs below, we made several changes to the NativeModule schema. This diff just ensures that the input to our generator snapshot tests, which are module schemas, are valid.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D23633942
fbshipit-source-id: 444ccd60f6ec76e348a8e54b946260464ff3aeee
Summary:
In the future, we'll use `NativeModuleArrayTypeAnnotation` inside JS struct objects. Structs cannot contain `ObjectTypeAnnotations` anywhere. Therefore, we need the elementType of `NativeModuuleArrayTypeAnnotation`'s elementType customizable.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645210
fbshipit-source-id: 97abb993d59536ebd68ec08b18ce7f2801c68a2d
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:
We were using `$ReadOnly<NativeModuleAliasMap>` everywhere, so I figured we'd just make the type itself `$ReadOnly`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23645207
fbshipit-source-id: 4e018d5768f4fcfd00492def7d840a5054cb2b73
Summary:
This diff introduces a `Required<T>` generic type in CodegenSchema. Why? NativeModule aliase RHSs are basically ObjectTypeAnnotations but they have `nullable` fixed to `false`. This generic type reduces duplication in the schema flow types.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23645208
fbshipit-source-id: da984f64fa17d8533a3ea74b132ce10aae9aa7ed
Summary:
This diff has a few changes:
- All type annotations are now declared top-level, and exported from `CodegenSchema.js`.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23616473
fbshipit-source-id: 1509c304305e56674bd76c44bc49f755dfeaa332
Summary:
Consider this case:
```
type Animal = ?{|
name: string,
|};
type B = Animal
export interface Spec extends TurboModule {
+greet: (animal: B) => void;
}
```
The generated output for this spec is:
```
namespace JS {
namespace NativeSampleTurboModule {
struct Animal {
NSString *name() const;
Animal(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
protocol NativeSampleTurboModuleSpec <RCTBridgeModule, RCTTurboModule>
- (void)greet:(JS::NativeSampleTurboModule::Animal &)animal;
end
```
Observations:
1. The codegen looks as though we wrote `+greet: (animal: ?Animal) => void;` as opposed to `+greet: (animal: B) => void;`
2. The generated struct is called `Animal`, not `B`.
## After this diff
Whenever we detect a usage of a type alias, we recursively resolve it, keeping a track of whether the resolution will be nullable. In this example, we follow B to Animal, and then Animal to ?{|name: string|}.
Then, we:
1. Replace the `B` in `+greet: (animal: B) => void;` with `?Animal`,
2. Pretend that `Animal = {|name: string|}`.
Why do we make all type alias RHSs required?
2. This design is simpler than managing nullability in both the type alias usage, and the type alias RHS.
3. What does it mean for a C++ struct, which is what this type alias RHS will generate, to be nullable? ¯\_(ツ)_/¯. Nullability is a concept that only makes sense when talking about instances (i.e: usages) of the C++ structs. Hence, it's better to manage nullability within the actual TypeAliasTypeAnnotation nodes, and not the associated ObjectTypeAnnotations.
## Other Changes
- Whenever we use the `Animal` type-alias, the e2e jest tests validate that the type alias exists in the module schema.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23225934
fbshipit-source-id: 8316dea2ec6e2d50cad90e178963c6264044f7b7
Summary:
## Test Structure
- Parameter Parsing
- For type in [optional, nullable, optional and nullable, required]:
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type alias
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
- Return Parsing
- For type in [nullable, required]:
- Can parse Promises
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type aliases
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23089925
fbshipit-source-id: 73c3b1ef33b402265c14f0ac9e364414a5d54dca
Summary:
This diff:
1. Simplifies the NativeModule schema Flow types.
2. Simplifies the NativeModule Flow parser, to accomodate the modified schema, and to reduce code duplication.
**Notes:**
- If the parser detects an unrecognized type within the context of parsing an Array's element type, it'll omit the `elementType` property of the `ArrayTypeAnnotation`. Details: T72031674. **Rationale:** Basically, when an array element type is supported, we use it in our generators. When it's unsupported, we ignore it. In the unsupported case, there's no point in trying to parse the Array element type, which is why I decided to omit the `elementType` property. Ideally, our NativeModule specs would never use unsupported types, in any context. This would allow us to always parse and use the elementType. However, that seems like a it could be a hefty migration: we have > 400 specs. Since, this isn't a battle we need to fight right now, I left a TODO at the relevant lines instead.
- The legacy codegen would generate structs for each object literal type in the file. In this re-implementation of the parser, I only insert into the aliases array when we detect a usage of a type-alias to an ObjectLiteral type annotation. With this decision, we won't be able to generate these unnecessary structs. This is good because we get rid of dead code. It's bad because it might make our migration to this codegen bit more difficult.
[WARNING] This diff produces flow failures that will be addressed in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23201387
fbshipit-source-id: 55ce0df925a8bae0e7d5bb2a9b63167607eba461
Summary:
## Changes
- Started doing cleanup under `/parsers/flow/modules/methods.js`
- Rename `NativeModuleMethodTypeShape` -> `NativeModulePropertyShape`
- Moved optional property from `FunctionTypeAnnotation` to the `NativeModulePropertyShape`
- Introduced a nullable property inside what was once `FunctionTypeAnnotation`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23146050
fbshipit-source-id: 2fe97bb9c0736242682133e4923131a54bbea54b
Summary:
## Changes
- Generating the aliases was split over `parsers/flow/modules/index.js`, and `parsers/flow/modules/aliases.js`. I moved everything to the latter file.
- Generating methods was split over `parsers/flow/modules/index.js` and `parsers/flow/modules/methods.js`. I moved everything to the latter file.
- More type-safety
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23143382
fbshipit-source-id: e11b76bee7917a7db37ae7f1af64da5f046c5d1e
Summary:
`buildSchema` delegates to two other functions: `buildComponentSchema`, or `buildComponentSchema`. Both return have a return type of *required* `SchemaType`. Therefore, `buildSchema` can have a return type of `SchemaType`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23135499
fbshipit-source-id: f13db17549c93b965f372d9b68d06efc2a40c6cc
Summary:
Just broke down getConfigType into two separate functions: `isModule` and `isComponent`.
- Cleaned up `isComponent`, to check for the the AST node types.
- Re-implemented `isModule`
- Improved error messages.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23121896
fbshipit-source-id: 3df2b2e334c4cea8eabe2e73ecb9f1f1217e7be4
Summary:
There are two types of types we care about:
- Type aliases
- Interface Declarations
These types can be exported.
I think we should build the types dictionary from only those types. Everything else should be ignored.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23120241
fbshipit-source-id: 9f023081d0f9c85b45407b180ae7c3e7391eb725
Summary:
Unecessary, since `NativeModuleShape` is the exact same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23119784
fbshipit-source-id: 8c4aded88a97a80aa977c13cc27e32fbe68150aa
Summary:
We already support type-aliases in our NativeModule method params. This diff extends the support to NativeModule method returns.
**Note:** I need to see if I need to update the generators to handle this case. Will do that in this diff, after working through other higher priority stuff.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828839
fbshipit-source-id: cf5c756d3cacf067df217cdb6212946320a2d4be
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
Summary:
This adds all the packages we use to the workspace in open source, which means we can change our publish scripts to also publish the packages from the repo every time we publish the main repo. I'll work with somebody from the community on that part.
Note: We do not use `eslint-config-react-native-community` internally and it pulls in a lot of packages we don't need. It is part of the React Native repo because it is used in the RN app template but we may want to choose to move it out into a separate repo at some point.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D23208695
fbshipit-source-id: 02d401721dfdc8bbb2305f8ac3381f1e98c18f1d
Summary:
This builds on the previous commit and complete all current NativeModule spec support for React Native Android:
* method param (nullable) typing
* promise return support
* sync method
* getConstants() special Android runtime validation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22862422
fbshipit-source-id: abc6d46fb8ce5863677910de1acc8bb6a927e7da
Summary:
* Allow generate-native-modules-specs-cli.js to generate Android specific files
* Add stub impl for Java spec generation (the output are still incomplete, see the next diffs for missing impl + tests)
* Adjust the CLI to only produce modules stuffs, there's no need to produce components code
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22860936
fbshipit-source-id: 38aae390189f143f6c6216995437ac1ff15a1788
Summary:
Sometimes mobile build systems just needs to provide the JS root dir to scan for NativeModules + NativeComponents, so let's support that directly in the CLI. This way, each build system doesn't have to do its own grep/crawling/filtering of files.
This will be needed for CocoaPods/Gradle integration.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22850011
fbshipit-source-id: fe202fa5e5a490af6d76fd10e761c9c3805fc11f
Summary:
`babel-plugin-codegen` will run the NativeModules codegen on each NativeModule spec, and inline the generated schema into the spec's `TurboModuleRegistry.get(Enforcing)?` call. This diff will forward that schema to `__turboModuleProxy` function (i.e: the TurboModule C++ infra).
**Note:** Both this and D2280384 can't be landed until D22743294 (https://github.com/facebook/react-native/commit/650c0f64f1262d26a31b61d2a7576c485f3efa13) hits production (1-2 weeks).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22832730
fbshipit-source-id: aecaf9943f9b01be805ff6b90249a6cbc6abdd20
Summary:
This diff:
- Moves the NativeModule flow types to the bottom of `CodegenSchema.js`.
- Re-organizes the NativeModuel flow type declarations based on when they're first used. Essentially, we start off by declaring a giant 'NativeModuleShape' type, which uses smaller undeclared types. Then we declare all the undeclared children of `NativeModuleShape`, and on and on. This way, you know where to start reading the types, and you can easily tell how every type relates to every other type.
Changelog: [Internal]
Differential Revision: D22828840
fbshipit-source-id: 5b4b9466a41b9bcb92a1de159bcbc12e4dc01df3
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
**Motivation:**
Match the old codegen's behavior when generating structs for type alias derived objects.
**Problem description:**
Take, for example, the following spec:
```
export type MyTypeAlias = { /* ... */ }
export interface Spec extends TurboModule {
// ...
+myMethod: (paramName: MyTypeAlias) => void;
// ...
}
```
The codegen needs to generate a struct to expose the properties of the type alias object. The codegen was producing the following output:
```
- (void)myMethod:(JS::MyModule::SpecMyMethodParamName &)paramName;
```
...which does not match the output from the original codegen:
```
- (void)myMethod:(JS::MyModule::MyTypeAlias &)paramName;
```
The original codegen generates a struct using the type alias name, while the new codegen was generating a struct that uses a combination of the property and parameter names.
Now that type alias names are exposed in the schema, the new codegen can match the original codegen's behavior.
**De-duplication of structs:**
Prior to these changes, type aliases were expanded into regular object types. This meant that any spec that used a type alias more than once would lead to redundant structs getting created. With these changes, we only generate the one struct per type alias, matching the old codegen.
**Expansion of type aliases:**
A new type was introduced in D22200700 (https://github.com/facebook/react-native/commit/e261f022fe6a7653b79330f878fed143725f5324), TypeAliasTypeAnnotation:
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
This type may now appear in several locations where a `{| type: 'ObjectTypeAnnotation', properties: [] |}` otherwise would have been used. A `getTypeAliasTypeAnnotation` function is introduced which, given an alias name and an array of aliases provided by the module, will produce the actual object type annotation for the given property parameter.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22244323
fbshipit-source-id: 125fbf0d6d887bd05a99bf8b81b30bdda4f1682b
Summary:
The current parser behavior flattens out any object type aliases into ObjectTypeAnnotations. Generators can treat these as regular objects and generate the applicable native code. This, however, can lead to repetition whenever an object type alias is re-used in the same native module.
I propose we treat these as a special case, using a TypeAliasTypeAnnotation to denote them as type aliases. Generators can look up the actual signature for a given object alias by referring to the "aliases" array that is provided in the schema.
**Proposed schema change:**
Adds an "aliases" key to each module in the schema:
```
export type NativeModuleShape = $ReadOnly<{|
properties: $ReadOnlyArray<NativeModuleMethodTypeShape>,
aliases: $ReadOnlyArray<{|
name: string,
typeAnnotation:
| $ReadOnly<{|
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<ObjectParamTypeAnnotation>,
|}>
| $ReadOnly<TypeAliasTypeAnnotation>,
|}>,
|}>;
```
Example:
```
{
modules: {
SampleTurboModule: {
nativeModules: {
SampleTurboModule: {
aliases: [],
properties: [],
},
},
},
},
}
```
Method parameters will now support the new 'TypeAliasTypeAnnotation' wherever a param might have used a 'ObjectTypeAnnotation':
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22200700
fbshipit-source-id: 15684620783c752f2fb482ba4b88d1fd1cc07540
Summary:
Moving property handling functions to their own properties.js file. No changes other than adding types to params.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22208243
fbshipit-source-id: 4a7d2c6e19c151954da793d399af9a256a4a40b7
Summary:
Move to Utils for reuse, and change parameter to take a property object.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22146669
fbshipit-source-id: e028821cdb11361a45226de0247aa4551b5ade1d
Summary:
Currently, the codegen supports `$ReadOnly` values, but not `$ReadOnly` properties on objects. This adds support for those (by pretty much ignoring them).
Changelog:
[General][Added] - Support `$ReadOnly` in object properties when defining native event types
Reviewed By: TheSavior
Differential Revision: D22023142
fbshipit-source-id: 7167852050925bf31392607923576f023e729f5f
Summary:
Restore legacy support for mixed union types.
These are not type safe and modules should use a different type, but we have a precedent for supporting these in the existing Linking native module. The new codegen will generate native code for these, and show a warning to encourage use of a better type.
Generate native code for elements in arrays of objects.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21848260
fbshipit-source-id: 0b8cbf25e7a02791b4d77e349227a2b0744854f4
Summary:
When a property returns an array type, use the actual element type when generating structs and inlines.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21651351
fbshipit-source-id: 14cadf209c38a301c9c65fcaadd8a292c1936349
Summary:
Handle properties named 'id' as a special case.
An example of a native module that ran afoul of this is `ExceptionsManager`.
Observe how the ExceptionsManager spec at `Libraries/Core/NativeExceptionsManager.js` defines the ExceptionData type as containing an `id` property:
```
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
Prior to this change, the generated code would redefine id in the SpecReportExceptionData struct...
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id() const; <---
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...which would result in a build time error:
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id() const
{
id const p = _v[@"id"];
^--- build time error here
return RCTBridgingToDouble(p);
}
```
Comparing the above example with the currently checked in `FBReactNativeSpec.h`, I see the expected output should be:
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id_() const;
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...and...
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id_() const
{
id const p = _v[@"id"];
return RCTBridgingToDouble(p);
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21395463
fbshipit-source-id: e412648013ff9f70ebd294b6f5f81f1faccb4604
Ramanpreet Nara
Kevin Gozali
Nat Mote
Christoph Nakazawa
David Vacca
Gijs Weterings
Héctor Ramos
Tim Yung
Lulu Wu