Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52252
Instead of declaring two different sets of Pods for prebuilt and build from source, this commit now keeps the pod structure the same for both modes so that consuming libraries can expect to have the same pods and header files available - without this, libraries would have to be updated to take advantage of the prebuilds.
This PR does:
- Added React-Core-prebuilt as a pod in React-Core if prebuilt is enabled
- Simplified react_native_pods to keep pods structure and add React-Core-prebuilt pod if prebuilts are enabled
- Added function for selecting source sets based on prebuilt/build from source
To be able to function both in prebuilt and in regular build from source mode, all podspecs are now using the switch function podspec_sources so that they only include header files if we are in prebuild mode.
Also added React-Core-prebuilt as dependency on React-Core if we are in prebuilt mode so that we install the React.XCFramework.
## Changelog:
[IOS] [FIXED] - Added backwards compatible use of prebuild through cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan:
Tested in RN-Tester both with and without prebuild.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77296047
Pulled By: cipolleschi
fbshipit-source-id: f3eb4d56b2a78bfc8e10ad852746be1ceaf828b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52194
Changelog: [Internal]
Introducing a way to include sources and deps via function that react_native_android_dep.
This will help with Fantom OSS build.
Reviewed By: cortinico
Differential Revision: D77146189
fbshipit-source-id: 06b09d433741506bc1f58fbf1f9e6add9a9cff91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51946
This change simplified the setp disallowing to use JSC from core.
As a side effect, it simplified the setup by always falling back to hermes if the users decides not to use the third party JSC
## Changelog:
[iOS][Removed] - remove the option to use JSC from core
Reviewed By: cortinico
Differential Revision: D76342625
fbshipit-source-id: c925ab4fab1e171e289a1c5f75890c92da1b3f08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51774
Changelog: [internal]
Just a small refactor to remove some unnecessary `using namespace` directives for code in the `facebook::react` namespace.
Reviewed By: javache
Differential Revision: D75874213
fbshipit-source-id: e63a91b412b2865eb05961d2174b14230ff35e88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51224
Changelog: [Internal]
We have a bunch of places where we rely on implicit conversion operators of `jsi::Value` and return some primitive type.
This doesn't work well with Bridging, because currently it doesn't take into account these implicit operator conversions: primitives won't be treated as primitivies, but rather as generic `jsi::Value`, which could be many things.
We should be explicit about return type in `toJs`, because it affects the type checking logic.
Reviewed By: javache
Differential Revision: D74478571
fbshipit-source-id: 0633159c5af3a02aafe14e2b137c133d4554a5f8
Summary:
JsErrorHandler throwing again masks what the real problem is.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D71920942
fbshipit-source-id: 1697f6f4c779d5c896df1be8e696a185f1c2c828
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49968
Updates all the core podspec to use the new `ReactNativeDependencies` podspec
## Changelog:
[INTERNAL] - Updates Modules in core to use the new dependencies.
Test Plan:
✅ Run Rn-Tester and verify that it works as expected both building deps from source and using prebuilt tarballs
✅ Add third-party library (react-native-reanimated) and perform the same tests to verify that it works with the changed podspec and utilities
Reviewed By: cortinico
Differential Revision: D71032639
Pulled By: cipolleschi
fbshipit-source-id: e53179a8c1b47ee2b945f5cb5dfaf3f6f2755af2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49803
This refactors the whole ReactCommon to use the `target_compile_reactnative_options` macro we just introduced.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D70386740
fbshipit-source-id: 1f15ea7e182d79bbb0bedce653284808e3309e4f
Summary:
I think parsed isn't a good enough name.
React native also does a lot of processing of the error.
This also opens the door for eventually forwarding the original error in the future.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D67526700
fbshipit-source-id: 895d64fa1ee4061ecbf0c1a6033c25b6fca95fd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47914
This was a bug in the original diff: D66193194.
If a fatal js error happens, we should only drop subsequent **fatal** js errors. It's fine to report soft errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66392706
fbshipit-source-id: c51bae186184c54faa9bce065b81b442607e751b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47889
## Context
When is the runtime ready?
- After the main bundle finishes executing **without** raising a fatal javascript error
## Changes
Let's decorate all errors reported while the runtime is not ready as "[runtime not ready]".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66316907
fbshipit-source-id: e48542af4f84d4cc3a6ce8f667dbaa10c30c19a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47783
After the first javascript fatal, the runtime starts tearing down. And it becomes invalid. So, subsequent js fatals will most likely be just noise. Let's filter them out.
This impacts bridgeless mode: both the javascript and c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66193194
fbshipit-source-id: 61a731850f7ac4f00bfac24e3260673bf94ba8ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47528
After the js pipeline fails to handle the error, reset the hasHandledFatalError var.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65678387
fbshipit-source-id: ac7cd4724954ea78bf33542e208c5f5d3dba5383
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47466
Now, when the useAlwaysAvailableJSErrorHandling feature flag is true, React Native will use the earlyjs c++ error reporting pipeline for handling all javascript errors!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64715159
fbshipit-source-id: 597a5278eb792f87dca10e06fa9816b3a8c47b84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46868
jsBuild prasing was done at the js level.
But, for the c++ pipeline, we have to parse the js build in native.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63927093
fbshipit-source-id: ce7ee46714ee0e72e450003330dbca78acb264a3
Summary:
## Changes
If the c++ pipeline is active:
If someone calls console.error:
- The c++ pipeline will report it as a soft error
If someone reports an error:
- The c++ pipeline will log it via console.error
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64506069
fbshipit-source-id: 293cd1774f19ee03d7eb61572b7b1f03a47a4756
Summary:
Now, handleError can be called with a JSError that wraps a non-error object!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64706198
fbshipit-source-id: 562ed7d4e2a13eaef48acfdf3499296462e54166
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46932
In the old error handling pipeline, when the app [assigns an object to error[ExceptionsManager.decoratedExtraDataKey]](https://fburl.com/code/9t9u8rgv)
```
const error = new Error('Some error happened');
// Annotates the error with some custom extra data.
error[ExceptionsManager.decoratedExtraDataKey] = {foo: 'bar'};
ExceptionsManager.handleException(error, true);
```
That object [gets forwarded as extraData](https://fburl.com/code/gy7v173u) to ExceptionsManager.
This diff implements that functionality within the c++ earlyjs pipeline.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63927091
fbshipit-source-id: ac88bf3e545714aa42531e8e1365e2eba32a7c2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46935
Now, whenever the earlyjs c++ pipeline handles an error, it'll invoke callbacks registered via javascript.
## The API
```
if (global.RN$registerExceptionListener != null) {
global.RN$registerExceptionListener(
(error: ExtendedExceptionData & {preventDefault: () => mixed}) => {
error.preventDefault();
// show logbox
},
);
}
```
## The Future API
We want something more aligned with the HTML spec:
```
addEventListener('error', (event) => {
event.preventDefault();
// show logbox
});
```
## Fatals vs soft errors
The earlyjs pipeline covers just main bundle execution for now.
So, it displays logbox only if there was a soft error. If there was a fatal error, it'll just continue to display redbox as usual.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63769385
fbshipit-source-id: 9c01e1cfe0ec80842af2e5bcfbf0adfb040dbcf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46895
For the js error handling pipeline, the javascript data structure looks like [this](https://www.internalfb.com/code/fbsource/[6181b57f4ba3619f58056bcec65382650d6ff59a]/xplat/js/react-native-github/packages/react-native/src/private/specs/modules/NativeExceptionsManager.js?lines=17-35):
```
export type StackFrame = {|
column: ?number,
file: ?string,
lineNumber: ?number,
methodName: string,
collapse?: boolean,
|};
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,
...
};
```
So, I made the c++ data structure look similar
```
struct ParsedError {
struct StackFrame {
std::optional<std::string> file;
std::string methodName;
std::optional<int> lineNumber;
std::optional<int> column;
};
std::string message;
std::optional<std::string> originalMessage;
std::optional<std::string> name;
std::optional<std::string> componentStack;
std::vector<StackFrame> stack;
int id;
bool isFatal;
jsi::Object extraData;
};
```
Notes:
* [parseErrorStack](https://fburl.com/code/e27q9gkc) doesn't actually generate a collapse property on the error object. So, I omitted it from the c++.
* ExceptionsManager [always provides an extraData field](https://fburl.com/code/2bvcsxac). So, I made it required.
* In C++, I just stored extraData as a jsi::Object. I wanted the freedom to store arbitrary key/value pairs. But, I also didn't want to use folly::dynamic.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D63929580
fbshipit-source-id: 51d8fcc79c9383789d456cfe4527cdd3f579395f
Summary:
This PR does some further cleanup on the flags passed to cocoapods.
I've moved `boost_compiler_flags` and `folly_dep_name` to `helpers.rb` file.
## Changelog:
[INTERNAL] [FIXED] - move boost compiler flags and folly dep name to centralized config
Pull Request resolved: https://github.com/facebook/react-native/pull/46513
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D62846105
Pulled By: cipolleschi
fbshipit-source-id: dff07ddb49f1f4b559125f2ed8508b32f08d4975
Summary:
If a fatal error is caught in js, and the js pipeline isn't ready, route it through the c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D60138414
fbshipit-source-id: 333e38e2b904d6434a88469816e39bf1b9d0bc3f
Summary:
If any fatal js error is caught in c++, just route it through js error handler.
Then, make js error handler call into the right pipeline:
1. After the js pipeline is ready: Route the errors through the js pipeline
2. Otherwise: Route errors through the c++ pipeline.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60138417
fbshipit-source-id: 24c466ffadbd14a9e9a5571548f3d34d2f406a8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45374
This change factors out the language standard in a separate constant so we can easily control it from a single place.
There are only 2 exception to this:
1. hermes-engine: the podspec is used in CI and it has no access to the rct_cxx_language_standard variable
2. Yoga: it can be used as a separate pod, outside of React Native, so it makes sense to leave it alone.
This change also fixes a problem where, in some setup, the language was set to C++14
## Changelog
[Internal] - Refactor Cxx language standard in a single constant
Reviewed By: dmytrorykun, blakef
Differential Revision: D59629061
fbshipit-source-id: 41eac64e47c14e239d8ee78bd88ea30af244d695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43985
This is just personal preference.
The name "OnJsError" makes the intent of the abstraction clear: an instance of OnJsError is a function that gets called when a js error is caught.
The name "JsErrorHandlingFunc" is not as good.
Changelog: [General][Breaking] - JsErrorHandler: Rename JsErrorHandlingFunc to OnJsError
Reviewed By: christophpurrer
Differential Revision: D55563580
fbshipit-source-id: 4d20bc984e6633aeac6193b9276a88d76961df2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43957
Right now, JsErrorHandler is only used to handle fatal exceptions.
So, let's just scope handleJsError down to handleFatalError.
Changelog: [General][Breaking] - JsErrorHandler: Rename handleJsError to handleFatalError
Reviewed By: cortinico
Differential Revision: D55547901
fbshipit-source-id: 261e0c8fea2852bc95e53c688d90d012d4abea34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43956
I think we should try to centralize all things js error handling related inside JsErrorHandler. So, I moved this bool into JsErrorHandler.
This makes ReactInstance easier to understand: it removes one member variable from ReactInstance.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547897
fbshipit-source-id: 73d1e0eedf3896c42cda4ce1013863960585da2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43951
## Context
The **early js** error reporting pipeline catches javascript exceptions.
After errors are caught, the pipeline parses the exception, and puts the data into into a map buffer. 🤨
## Problems
We don't need to use a mapbuffer here: The structure of this exception data is known and never changes. (A map buffer is a type-unsafe bag of key/value pairs).
Instead, we could just use lower-level type-safe language primitives: regular C++ struct, and java class w/ fbjni.
## Changes
Migrate the **early js** error handling infra to C++ structs/fbjni.
## Impact
Now, there is no mapbuffer usage on iOS. We could re-introduce it when there is a need.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55265170
fbshipit-source-id: cda97633d4c6ccaad541e5d416067390fe6f61b2
Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42136
`Wpedantic` flags usage of variadic macros with zero arguments. This is widely supported by different compilers (including MSVC), but was previously forbidden by the standard.
C++ 20 explicitly allows them, so, theoretically Clang should know not to warn about these now. Let's try that.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52534129
fbshipit-source-id: e27a75081fac6b4196c6dbb5242812877b0bd679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41815
Our Apps in OSS ends up shipping with too many .so files.
I'm attempting to move several libraries from dynamic to static.
This is a first round of it affecnting only libraries which are not
exposed via prefab and that are not having an OnLoad method
Changelog:
[Internal] [Changed] - Move several libraries to static linking
Reviewed By: NickGerleman
Differential Revision: D51895785
fbshipit-source-id: 1ba2dbbbae6b6c2639ba0e064f1b331b2a157f03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41359
This change migrates the remaining podspecs to the new functions, so we do not depend on hardcoded values anymore and we can scale the solution to other platforms.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068403
fbshipit-source-id: 4c0455543363ccf4272d5e8590a7c663d9c33e8b
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
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:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
This changes Clang format config to enforce left pointer alignment instead of right, in accordance with https://www.internalfb.com/intern/wiki/Cpp/CppStyle/
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: sammy-SC
Differential Revision: D48952040
fbshipit-source-id: 108329b2f11d2041a31dee3334c7801d69a3f1ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36964
Changelog: [Internal]
W/o #pragma once, .cpp files would include the same header file content multiple times leading to compile errors as
```
react-native-github/packages/react-native/ReactCommon/jserrorhandler/JsErrorHandler.h:14:6: note: unguarded header; consider using #ifdef guards or #pragma once
enum JSErrorHandlerKey : uint16_t {
^
```
Reviewed By: shwanton
Differential Revision: D45100413
fbshipit-source-id: 9a8a03624b9475506caf1e485dc8a06a7f14c1e5
Summary:
## Changelog:
[Internal] -
While merging a Contributor PR in D43816768, I got curious whether such things as detecting/fixing typos could be automated.
There is a tool called [typos](https://github.com/crate-ci/typos), which, as it turns out, works very well on source code files.
The amount of false positives was minimal, most of the suggestions were valid ones.
And the total amount of typos found and fixed was **more than 300**, which is... quite a bit :)
### Methodology
* Run `typos` separately on `ReactCommon`, `Libraries`, `React`, `ReactAndroid` and `scripts` folders inside `packages/react-native`, e.g.:
```
$ typos -w --config ~/tmp/_typos.toml ~/fbsource/xplat/js/react-native-github/packages/react-native/ReactAndroid
```
Contents of the `_typos.toml` config file:
```
[default.extend-words]
collapsable = "collapsable"
NDK = "NDK"
inout = "inout"
```
(yeah, it really didn't like the "collapsable" word, for some reason ;))
* Inspect all the changes manually and revert false positives (as mentioned, their amount was minimal)
Note that most of the changes are inside things like comments and error messages, however there are a few among identifier name fixes (`typos` is actually quite smart at understanding naming conventions in code) - I kept the suggestions in cases that are local and not part of a public API. There are also misspelled file name changes in a couple of cases.
Reviewed By: NickGerleman
Differential Revision: D44172494
fbshipit-source-id: 86e27edbbb99e09135e3cdd5d7cea8ffeb8307f4
Christian Falch
Andrew Datsenko
Riccardo Cipolleschi
Tim Yung
Rubén Norte
Ruslan Lesiutin
Danny Su
Nicola Corti
Ramanpreet Nara
Oskar Kwaśniewski
zhongwuzw
Riccardo Cipolleschi
Kudo Chien
Nick Gerleman
Nick Gerleman
Saad Najmi
Lulu Wu
Christoph Purrer
Ruslan Shestopalyuk