Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33897
Now the exception will display the class which caused the exception as well as helpful information as to why.
We've seen this happen a bunch due and have been very confused by the error message. It turns out that this processor runs before the classes listed are compiled. This means that if there's a compile error (or a missing import) the user will only see that this processor crashed, and not the compile error.
The additional information in the error is:
`java.lang.RuntimeException: Could not load classes set in ReactModuleList.nativeModules. Check that they exist and are imported correctly on class: com.meta.x.y.ReactPackage`
In this case, `com.meta.x.y.ReactPackage` is the class which needs to be fixed. Before, the error message made no mention of this class or the annotation.
Changelog: [Internal] This will change the way the annotation processor crashes. It will throw a RuntimeException instead of a ClassCastException.
Reviewed By: javache
Differential Revision: D36606279
fbshipit-source-id: aedf9682286fba49e23716b7eda16b2dd3b13422
Summary:
WHen porting TurboModules or adding new TurboModules, ReactModuleSpecProcessor may fail during buck build, and when the failure is caused by typeElement.getAnnotation, no useful information gets collected, making it difficult to debug.
So here I am adding a try & catch so we can get useful debugging info.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D35767207
fbshipit-source-id: 7e1f9dfbfd31339ab37af19c51d85085e100955a
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
## Problem
For efficiency reasons, we'd only check whether the current class or its superclass implemented the `TurboModule` interface. However, it's possible for NativeModules to exist that use inheritance, and have their base class extend a code-generated spec. In this case, the superclass of the superclass of the NativeModule will implement `TurboModule`.
## Solution
To fix this problem, I'm relying on the `Types.isAssignable` API and checking whether the NativeModule can be assigned to the `TurboModule` interface. This is a more reliable way of knowing whether a NativeModule is a TurboModule or not.
**Note:** Had to adjust the buck dependencies of FrescoModule to make the `mTypes.isAssignable` check work.
Changelog:
[Android][Fixed] - Correct TurboModule detection logic in ReactModuleSpecProcessor
Reviewed By: fkgozali
Differential Revision: D19183671
fbshipit-source-id: ad21881453fe7027d9432048108f6ba344fd7e63
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
Added a flag that checks if TurboModules are enabled, don't expose them to JS via the old module system.
All TurboModules needs to implement TurboModule interface.
Reviewed By: mdvacca
Differential Revision: D13648332
fbshipit-source-id: f22506fe029ac82d56075f5b6962ff2df2e7eaa4
Summary: The annotation ReactModuleList that was processed by ReactModuleSpecProcessor.java does not use ViewManagers. Removing this method from the annotation so that there is no confusion on how view managers are added to individual packages.
Reviewed By: achen1
Differential Revision: D9115363
fbshipit-source-id: 43d12e09b0e9b8e1732533f9a4456327778a0eaf
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Currently `ReactModuleSpecProcessor` looks at each of the modules, and sees if the module inherits from `CxxModuleWrapper` to see if it is a C++ module or not. With this change, we now require C++ modules to explicitly specify that they are C++ modules, instead of doing annotation processing magic.
Also note that annotation processor do not work with interfaces but with classes only, so this also removes the dependency of the annotation processor from the bridge buck target.
Reviewed By: achen1
Differential Revision: D9597352
fbshipit-source-id: fd847ac382699d2ab78f7d7c6e2dbd7c60d3f0c4
Summary:
Currently, we scan all native modules to see if they implement the OnBatchCompleteListerner. If they do, we add those modules to a list, and when C++ calls OnBactchComplete is called, we execute the callback on each of the modules.
The only native module implementing this callback today is the UIManagerModule. With Fabric, UIManager will also not be a native module anymore. This diff removes all the work done for creating the list and assumes that UIManagerModule is the only place that is interested in OnBatchComplete call - and calls it directly.
Reviewed By: achen1
Differential Revision: D9186651
fbshipit-source-id: 473586b37c2465ccd041985dcdd56132026f34f1
Summary:
When native modules use `LazyReactPackage`, the modules themselves are not initialized. However, they still use the class names, causing the classes to load. This diff removes the need to perform any class loads. Any properties of the classes that are required are now populated in the `ReactModuleInfo` of that class.
Note that this diff itself does not prevent class loading since any references to `*.class` in `LazyReactpackage` needs to be removed in a consequent diff
Reviewed By: achen1
Differential Revision: D8950025
fbshipit-source-id: 80ddf7e1f33bf2af0db1bd262069795de77ec611
Summary: `ReactModuleInfoProvider` was using `Class` as the keys. This would make the classes to load. This change makes the map use canonicalName Strings of the classes, removing the need for the classes to load at this point.
Reviewed By: achen1
Differential Revision: D8944078
fbshipit-source-id: 4aa562d74d6ad3ebb9962b581d4e2f5e89d47ca6
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
