Summary:
Changelog: [Internal]
In the new architecture, when an interop component is being called, log instead of warn/error, since at the moment we expect this to happen often.
Reviewed By: fkgozali
Differential Revision: D34252666
fbshipit-source-id: 971156a1cd9ef9b788f677c49fa2c55bd86ad4fa
Summary:
Changelog: [Internal]
# Diff Changes
- Set `RCTEnableNewArchitectureViolationReporting` to YES in app-wide Bridgeless mode.
- Rename `RCTWarnNotAllowedForNewArchitecture` to `RCTErrorNotAllowedForNewArchitecture`, and use `RCTLogError` instead of `RCTLogWarn` so the error goes to Logview.
Reviewed By: RSNara
Differential Revision: D34202682
fbshipit-source-id: 471486c65f7a42f8f11140e61ff60592dc826f61
Summary:
To prepare for the new architecture, introduce the following enforcement:
* Defining `RCT_NEW_ARCHITECTURE` in the build flag automatically enables violation reporting
* At runtime, call RCTEnableNewArchitectureViolationReporting() to enable/disable reporting - it takes effect with the future violations
* When violation reporting is enabled:
* RCTWarnNotAllowedForNewArchitecture(): log warning about a violation, but doesn't assert
* RCTEnforceNotAllowedForNewArchitecture(): assert when a violation happen
Also in this commit:
* Add warning when RCTRegisterModule() is called as a side effect of RCT_EXPORT_MODULE(). Many modules still need this, so we can't enforce it yet.
* Add enforcement when the bridge is initialize, because the new architecture cannot have the bridge.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D27847359
fbshipit-source-id: a8c4a8151cec3915ec707ce6b78f860af4bb0708
Summary:
In order to move away from the legacy system (bridge etc), we need to decouple the new architecture assumptions from it. This flag and assertion functions will help track the runtime and report violations along the way. The goal is to have 0 violation before switching over to the pure new architecture.
Note: this is not used right now.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27783246
fbshipit-source-id: 61f0d77c129bddcde7f24a803432f2d359c5bff3
Summary:
When we catch an Objective-C exception and convert it to NSError we need to somehow represent the call stack from NSException instance in NSError instance. For now, we just attach the stack trace to `message` field.
The next step would be to figure out how to pass the Objective-C stack trace to error reporting infra to help it to display the stack trace nicely in the web interface.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23557600
fbshipit-source-id: a080c2e186e719e42dcfc01bb12f5811e3c5b2e6
Summary:
Extracts a new `RCTFormatStackTrace` function from `RCTFormatError`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18114387
fbshipit-source-id: 4466f52d75d9da3a257cd1cc7067492a0c19a7d5
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
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:
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
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary: public
Removed redundant calls to [RCTNetwork canHandleRequest] in release mode when loading images, and improved perf for handler lookups when running in debug mode.
Reviewed By: tadeuzagallo
Differential Revision: D2663307
fb-gh-sync-id: 13285154c1c3773b32dba7894d86d14992e2fd7d
Summary: I changed the format slightly of the exception being generated in RCTFatal, so we we're catching and rethrowing it, which left some useful information of the error stack.
public
Reviewed By: majak
Differential Revision: D2631341
fb-gh-sync-id: feb4939f58014171a55cd74f20f57bcd6dfddc1e
Summary: public
Add RCTFatal for reporting fatal runtime conditions. This centralizes failure handling to one function and allows you to customize how they should be handled. RCTFatal will be logged to the console and as a redbox and will also be triggered by fatal exceptions coming from RCTExceptionsManager.
Note that there is no RCTLogFatal, since just logging the fatal condition does not allow us to handle it consistently.
Reviewed By: nicklockwood
Differential Revision: D2615490
fb-gh-sync-id: 7d8e134419e10a8fb549297054ad955db3f6bee0
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
Add `RCTAssertThread` to `RCTAssert.h` for convenience when checking the current/queue,
it accepts either a `NSString *`, `NSThread *` or `dispatch_queue_t` as the object to be checked
Also add a check to `-[RCTUIManager addUIBlock:]` - There was a discussion on github (https://github.com/facebook/react-native/issues/1365)
due to the weird behavior caused by calling it from a different thread/queue (it might be added after `batchDidComplete` has been called
and will just be dispatched on the next call from JS to objc)
Test Plan:
Change `-[RCTAnimationExperimentalManager methodQueue]` to return `dispatch_get_main_queue()` and run the 2048 example,
it should dispatch with a helpful message (screenshot on the comments)
Paige Sun
Andres Suarez
Kevin Gozali
Valentin Shergin
Moti Zilberman
Pavlos Vinieratos
Héctor Ramos
Hoa Dinh
Sophie Alpert
Pieter De Baets
Marc Horowitz
Nick Lockwood
Tadeu Zagallo