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:
NativeModule specs exist under `react-native-github/packages/react-native-codegen/src/__tests__/modules/fixtures`. `GenerateModuleObjCpp-test.js` runs the RN Codegen on those NativeModule specs, and saves the output inside a snapshot. For convenience, the folowing command runs the legacy codegen on the fixtures:
```
buck build fbsource//xplat/js/react-native-github/packages/react-native-codegen/src/__tests__/modules:RNCodegenModuleFixtures-flow-types-ios --show-output
```
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23637708
fbshipit-source-id: 3319f319515eca42b4499682313fea6e0bdc2a06
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 small PR includes the following changes:
* deduplicate yarn lock file using [`yarn-deduplicate`](https://github.com/atlassian/yarn-deduplicate) package
* deduplicate script has been added as `update-lock`, let me know if you would like also to see this in [`postinstall`](https://docs.npmjs.com/misc/scripts) (to automatically optimize lock on every dependency change)
* according to the [npm docs](https://docs.npmjs.com/files/package.json#repository):
* main `package.json` repository field has been replaced with shorthand
* monorepo packages repository field has been extended by `directory`
The main goal of introducing deduplication script was to optimize the dependencies footprint while developing and speed up the initial installation process. Running `yarn-deduplicate` also increase the security in some way, because it enforces usage only of the latest version of the package. You can read more about the benefits in the deduplicate script [repository](https://github.com/atlassian/yarn-deduplicate#duplicated-packages).
## 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] [Added] - add yarn lock deduplication script
Pull Request resolved: https://github.com/facebook/react-native/pull/30044
Test Plan: `yarn install` was successful, this also should not affect yarn workspaces in any way.
Reviewed By: GijsWeterings
Differential Revision: D23959812
Pulled By: cpojer
fbshipit-source-id: e2455e3718378e1ce6206e79463d4083f8fe5d47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014
This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.
Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html
Note that `ANDROID_NDK` env var is honored to pick the right NDK version.
For now, this is gated behind `USE_CODEGEN` env variable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23887058
fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
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:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Summary:
Move the directory creation logic to the CLI. This needs to be processed by RNCodegen.js eventually.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618550
fbshipit-source-id: e7dc4f5fc37e5ad12b5c6ae8ea31fc9ef16d74b9
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:
The nested `.gitattributes` file in `packages/react-native-codegen/android/` caused some confusion on Linux and macOS, causing Git to show `packages/react-native-codegen/android/gradlew.bat` as modified (CRLF removed, LF added).
Instead of relying on repo-local `.gitattributes` files to convert endings in the working directory, the files should be committed to source control with the correct line endings in the first place. There is no reason to convert LF endings in .sh and many other file to CRLF on Windows (maybe this was an issue a long time ago, but unless Notepad is used this won't be a problem for practically all modern editors).
Also fixed the line endings of `scripts/launchPackager.bat` which was incorrectly committed as LF.
## Changelog
[Internal] [Fixed] - Line endings and .gitattributes
Pull Request resolved: https://github.com/facebook/react-native/pull/29792
Test Plan: Clone repo on Linux, macOS, and Windows, and make sure no modified files show up.
Reviewed By: fkgozali
Differential Revision: D23546135
Pulled By: mdvacca
fbshipit-source-id: 1572fcb959212f212b137066f1aa66f0bb6e86c3
Summary:
`-all` is the **default** for projects generated by Android Studio, and it provides **additional sources** helpful for debugging. It's also much more likely to already exist on a developer's machine (which has built other Android projects), avoiding additional downloads and saving disk space.
`-all` has also been the variant used in `react-native` for all versions prior to 5bc67b658e.
Follow-up to https://github.com/facebook/react-native/issues/29613
## Changelog
[Android] [Changed] - Use Gradle Wrapper 6.6 (-all variant)
Pull Request resolved: https://github.com/facebook/react-native/pull/29793
Test Plan: No test needed since versions are the same.
Reviewed By: fkgozali
Differential Revision: D23406546
Pulled By: mdvacca
fbshipit-source-id: b74dbbfc0317bccf1940b1e5062d866e50aed28a
Summary:
This implements the full NativeModuleResolvedType for each NativeModule spec, producing .java spec files in the output directory. The output files are now compiled during build time for :ReactAndroid and :packages:rn-tester:android:app.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23312858
fbshipit-source-id: c521b9d6602677fd275891cf44329740c6bd7387
Summary:
For each resolved type, define how to process its own type and whether it should produce generated code/file, minus the NativeModuleResolvedType (will be in the next commit).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23307961
fbshipit-source-id: 87af09867aace7a5ff060a33a00b141048630eda
Summary:
This is the base setup for ResolvedType. Each Type needs to be resolved to its final representation, which knows what Java type it needs, and what standalone Java code (e.g. class) it needs to produce. Individual resolved types are not yet implemented, this commit provides the flow to pass the parsed structure (from schema) to the resolution logic.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23288208
fbshipit-source-id: 18535d5fae8ca15f6d9374bdba38f57dfd4300e8
Summary:
Instead of recreating the schema structure, the generator only needs to collect the list of types that it needs to generate for. So instead, let's just add each parsed type into a map using TypeId as the key. This means every inner types in the schema needs its own unique TypeId. This was a change from the previous commit where we didn't assign unique names to the types. Here's the reasoning:
* In Java, any generated class needs to be in its own file.
* If a NativeModule spec defines a few aliases, and or inner types (function args, return type shape, etc) that needs representation with a dedicated class, we need to track them as well for code generation.
* This means, the schema format is no longer relevant for the code generation step, so let's produce a structure that's more efficient for code generation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23287818
fbshipit-source-id: 7caf4e95aeafe5c8ba336af290179b85bf87ad6d
Summary:
Instead of invoking JavaGenerator when the task is registered, do it when the task actually executes. This way, it will wait until the other task it depends on to finish executing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23276359
fbshipit-source-id: 6aea98d97121f2dcfd83b299e38debc767f08240
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 diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
Summary:
This parses the JSON schema's aliases and reserved function valye types. It also assigns TypeId correctly now:
* TypeId is an identifier for a specific type, that can be referred by others
* This means only aliases should have TypeId.typeName. Properties' names are not typeNames
* NativeModule spec's typeName is hardcoded to `Spec`, see T71955395
This way, whenever we encounter an `AliasType`, we can just lookup the actual Type by a quick Map lookup with TypeId as the key.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23181432
fbshipit-source-id: 9d0ea17dbf601589d8f3fc1955e0c9406a80e244
Summary:
This parses the output JSON schema into Java Type's, without any alias resolution. Some parts of the schema have incomplete information, hence a bunch of TODOs in the code expressing the issues.
Notes:
* The type structure here could be implemented in other codegen generators as well (including the RNCodegen.js' generators) for better type safety and correctness. With this exercise, I was able to catch a few issues mentioned above.
* This commit does not produce any Java code with JavaPoet yet, just parsing the schema.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23152891
fbshipit-source-id: 9f774dd98975f7202d3faf11c3fbfb83d4c97f5a
Summary:
This new buck target will execute the code gen and copy C++ files to the output directory. This will be used to integrate these files into RN Tester
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23115538
fbshipit-source-id: de4135be697c36cd559edf416986299511c31744
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
Ramanpreet Nara
simek
Kevin Gozali
Frieder Bluemle
Nat Mote
Christoph Nakazawa
David Vacca