Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48458
NOTE: This change is made once and is not guaranteed.
**Motivation**: Requiring Flow parsing for `react-native` and its dependencies in user space can involve friction. For the case of `react-native/assets-registry` → `react-native-web`, I believe we should do the pragmatic thing to relax this requirement.
- This is a convenience stopgap until https://github.com/facebook/react-native/pull/39542 can be stabilised.
- This package is tiny and infrequently modified — I believe it's pragmatic/safe to do a one-time conversion, with the above notice and no changelog (i.e. "experimental" for now).
Resolves https://github.com/facebook/react-native/issues/48349.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D67764460
fbshipit-source-id: 7687fd79c6dea73c234a46e475c1cc745225830b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48443
This change makes sure we build the Release variant of RNTester so we can store the generated app as an artifact and forward it to the E2E tests.
## Context
While looking at the recent failures of the E2E tests, I realized that the Hermes, NewArch, Debug variant often fails to build, not to test, for some misconfiguration.
I also realized that we are already building that varaint successfully once, so why not reuse it? To reuse prebuilds, we need a few steps:
1. make sure we build all the variants we need
2. store the .app file as an artifact
3. download the artifact and use it in the E2E tests
## Changelog:
[Internal] - Build release variant for RNTester
Reviewed By: cortinico
Differential Revision: D67760372
fbshipit-source-id: 02cc9ec64d5a7b4fa2ad05bca6aa91a69b2b5907
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48419
This change moves the E2E scripts for iOS to a JS script.
This should make it much easier to modify the code in case we need to change it.
## Changelog
[Internal] - Move e2e script from bash to JS
Reviewed By: cortinico
Differential Revision: D67737950
fbshipit-source-id: d0b0411c8a4d688c10e460e70b11dbfc83aaa135
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48418
RNTester JSC Debug is currently insta-crashing on the 0.77 release branch due to:
```
12-31 10:59:36.388 15165 15204 E ReactNativeJS: React Native version mismatch.
12-31 10:59:36.388 15165 15204 E ReactNativeJS:
12-31 10:59:36.388 15165 15204 E ReactNativeJS: JavaScript version: 0.77.0-rc.5
12-31 10:59:36.388 15165 15204 E ReactNativeJS: Native version: 1000.0.0-bb9d7ad9a
12-31 10:59:36.388 15165 15204 E ReactNativeJS:
12-31 10:59:36.388 15165 15204 E ReactNativeJS: Make sure that you have rebuilt the native code. If the problem persists try clearing the Watchman and packager caches with `watchman watch-del-all && npx react-native start --reset-cache`.
```
This is causing a `console.error` that is resulting in the crash as one of the frame in the stack doesn't have the line/column number information. Calling `.putDouble(string,double)` is forcing a conversion from `null` -> `double` which is result in the crash.
This is happening only on CI because the `set-rn-version` step on GitHub Action is executed with `--dry-run` (as this is not a release run) so the version of React Native is set back to `1000.0.0-<SHA>`. Locally this doesn't happen because the React Native version is read from the local file which is never manipulated by the `set-rn-version`.
Changelog:
[ANDROID] [FIXED] - Fix JSC Debug instacrashing
Reviewed By: cipolleschi
Differential Revision: D67735962
fbshipit-source-id: 363218385277374d33b8313cacd14159b2f17106
Summary:
### Issue
When a real device is oriented into landscape and the user locks the screen during said orientation incase the user rotates back to previous orientation and unlocks the screen `useWindowDimensions` will not get the correctly updated values. This is due to `applicationState` being equal to UIApplicationStateInactive still when `interfaceFrameDidChange` gets called.
### Fix
`didUpdateDimensions` on iOS. Now correctly emits the dimension values after the device has been oriented and device has been locked. By adding `UIDeviceOrientationDidChangeNotification` to `NSNotificationCenter`
## Changelog:
[IOS] [FIXED] - Emit didUpdateDimensions correctly
```
// RCTDeviceInfo.mm
// Adds the interfaceFrameDidChange to UIDeviceOrientationDidChangeNotification
[[NSNotificationCenter defaultCenter] addObserver:self
selector:selector(interfaceFrameDidChange)
name:UIDeviceOrientationDidChangeNotification
object:nil];
```
Pull Request resolved: https://github.com/facebook/react-native/pull/46353
Test Plan:
### ***Note***: This doesn't seem to be replicable on simulators. It only happens on real iOS devices.
### Before change:
Rotate Device > Lock Screen > Rotate back to portrait > Unlock phone
### After change:
Same steps as above, now emits correct values
Reviewed By: cortinico
Differential Revision: D67735523
Pulled By: cipolleschi
fbshipit-source-id: 146e5d62d55eeef0f6b17f962ca84ab418a7b7f0
Summary:
This PR implements ReactNativeFactory to encapsulate further the logic of creating an instance of React Native for iOS.
This will remove the strong coupling on the RCTAppDelegate and allow us to support Scene Delegate in the future.
The goal is to have a following API:
```objc
self.reactNativeFactory = [[RCTReactNativeFactory alloc] initWithDelegate:self];
UIView *rootView = [self.reactNativeFactory.rootViewFactory viewWithModuleName:self.moduleName
initialProperties:self.initialProps
launchOptions:launchOptions];
// Standard iOS stuff here
```
## Changelog:
[IOS] [ADDED] - implement ReactNativeFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/46298
Test Plan: Test out all the methods of AppDelegate
Reviewed By: huntie
Differential Revision: D67451403
Pulled By: cipolleschi
fbshipit-source-id: 9e73cd996ffc27ca1e3e058b45fc899b1637bdba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48347
Vector drawable support was added behind a feature flag in https://github.com/facebook/react-native/pull/45354 and is ready to release more widely. This change is effectively the same as removing the feature flag but allows our holdout to continue until mid-January.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67482531
fbshipit-source-id: 1733c4748f79fd4df72f531a24efcbd8a7822611
Summary:
X-link: https://github.com/facebook/litho/pull/1036
X-link: https://github.com/facebook/yoga/pull/1775
Pull Request resolved: https://github.com/facebook/react-native/pull/48404
## Changelog:
[Internal] -
This popped up when profiling some heavy UI performance, calling `fmod` operation in Yoga's `roundLayoutResultsToPixelGrid` in `PixelGrid.cpp` can be expensive, furthermore it turns out that some of the calls were redundant.
This replaces the duplicate calls to fmod with an equivalent single round operation, which for e.g. clang compiler on Windows brings the code in question from ~50 instructions (including 4 call instructions to the fmod function) down to ~30 instructions (without any external calls), and the layout operation being **~1% more efficient** for the particular benchmark I was looking into.
Reviewed By: christophpurrer
Differential Revision: D67689065
fbshipit-source-id: 2a074a1cb81bd7f7a3c414050b9ddda2ba90180f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48401
This change adds a flag to JS Error's prototype to specify the jsEngine.
Reviewed By: fkgozali
Differential Revision: D67665484
fbshipit-source-id: 64b7b4bd986bcbd45d58e70c1a16de6752b05ccd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48400
A couple of days ago, the iOS CI started failing for the E2E tests on main.
This is because We were not using the hermes artifacts we were preconfiguring.
In fact, this is the log of the `test_e2e_ios_rntester`, which is not using the prebuilt.
{F1974129000}
For comparison, this is the `test_ios_rntester`, which is using the prebuilt
{F1974129001}
While investigating why this was happening, I realized that we were not testing the old architecture anymore, because we forget to update the script after the release of the New Architecture.
This change should fix both.
## Changelog:
[Internal] - Fix E2E tests for iOS and test the Old Arch
Reviewed By: robhogan
Differential Revision: D67670976
fbshipit-source-id: 7d1383a89e06c138f437a9c5f876a2e900878fb0
Summary:
### Error message:
we got an error
```
t[n] is not a function. (In 't[n]()', 't[n]' is undefined) \n <unknown> (index.bundle:317:168:317)
```
it related the BackHandle execute handle function.
### Investigation result
our project has screen files`App.tsx`, `Dashboard.tsx`, and `Profile.tsx`.
When launching the app, the screen order is `App.tsx` -> `Dashboard.tsx`, then user can switch to `Profile.tsx`
For `App.tsx` and `Dashboard.tsx`, we just prevent the hardware button action use `usePreventHardwareBackPressEffect()` in the first line of screen code.
```js
export const useHardwareBackPressEffect = (goBack?: () => boolean): void => {
useEffect(() => {
if (goBack) {
BackHandler.addEventListener("hardwareBackPress", goBack);
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
}
return undefined;
}, [ goBack ]);
};
export const usePreventHardwareBackPressEffect = (): void => useHardwareBackPressEffect(() => true);
```
currently, `_backPressSubscriptions ` has 2 callback functions.
then user switch to `Profile.tsx` screen, and has the below code for hardwareback button and the second doesn't `return true`:
```js
// first one
usePreventHardwareBackPressEffect();
...
// second one
useEffect(() => {
const backButtonListener = BackHandler.addEventListener(
"hardwareBackPress",
() => navigate(Navigation.Login);
);
return () => backButtonListener.remove();
});
```
currently, `_backPressSubscriptions ` has 4 callback functions, include previous 2 and new 2 of `Profile.tsx`.
When the user press hardwareback button, it will navigate to the login screen, so the issue occurs:
the latest callback will be executed first, then the navigation will let the screen unmount, which will destroy the effect, so the code removing 2 hardwareBackPress callback of `Profile.tsx` by executed
```js
return () => {
BackHandler.removeEventListener("hardwareBackPress", goBack);
};
```
After the navigation ends and the loop is restored, the init `i` is 3, then `i--`, `i` is 2, then `_backPressSubscriptions[2]` is `undefined` now and executes as a function, so the app crashes.
```js
for (let i = _backPressSubscriptions.length - 1; i >= 0; i--) {
if (_backPressSubscriptions[i]()) {
return;
}
}
```
that's the issue I met.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix BackHandle callback undefined cause crash issue
Pull Request resolved: https://github.com/facebook/react-native/pull/48388
Reviewed By: blakef
Differential Revision: D67648077
Pulled By: rshest
fbshipit-source-id: 5ca685b0c0c474ef11772fd803743968ec2d912e
Summary:
https://github.com/facebook/react-native/issues/48376 removed `applicationDidEnterBackground` from `RCTAppDelegate` but RNTester called it, leads to crash. cc cipolleschi can you please help to review?
## Changelog:
[INTERNAL] [FIXED] - RNTester: Fixes crash when app back to background
Pull Request resolved: https://github.com/facebook/react-native/pull/48385
Test Plan: RNTester iOS back to background not crash.
Reviewed By: cipolleschi
Differential Revision: D67657449
Pulled By: philIip
fbshipit-source-id: e6d806b2677050fa2faa273a7468055d9d21c2a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48383
## Changelog:
[Internal] -
This changes the name of `SystraceSection` class to `TraceSection`, the purpose being to make it Systrace/FBSystrace agnostic (and that it can be mapped to e.g. Perfetto instead).
It changes all the internal callsites to the RN code code, and also adds a shim include, `<cxxreact/SystraceSection.h`, for backward compatibility with the external callers for now (which will be addressed separately).
Reviewed By: javache
Differential Revision: D67621914
fbshipit-source-id: 337c63c45a7b075c6e00cfca67ecc06c298c94c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48381
Right now, the E2E tests for RNTester does not have a timeout.
It can happen that the emulator get stuck and the action times out.
The default timeout is 6 hours, which is definitely too much and wasteful, so let's reduce it to 1 hour.
{F1974112110}
## Changelog:
[Internal] - Set timeout for E2E tests to 1 hour
Reviewed By: robhogan, blakef
Differential Revision: D67620423
fbshipit-source-id: c507d1222fca49287fafe6da4bffe559d8687b99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48379
## Changelog:
[Internal] -
We have a good portion of RN core code already instrumented with `SystraceSection` blocks, and those do the timing via fbsystrace, which may or may not be enabled in the system and generally is obsolete.
This maps the blocks to the corresponding Perfetto instrumentation, in case the latter is enabled, which will allow to get this information in Perfetto sessions without need to have fbsystrace present.
Reviewed By: javache
Differential Revision: D67619443
fbshipit-source-id: 52e5666472ad118fbec176a0e82d72a5200a358a
Summary:
While investigating the root cause of app hanging on older devices in Instruments, I noticed that the heaviest stack trace was pointing to `RCTRecursiveAccessibilityLabel` in RCTView.m.
<details>
<summary>Heaviest stack trace in Instruments</summary>
<img width="473" alt="Screenshot 2024-05-17 at 4 22 48 PM" src="https://github.com/facebook/react-native/assets/849905/fab8ed01-7a2f-4113-b2ca-04e76f25cd9d">
</details>
The profiling was done on an iPad (5th generation) running iOS 16.7.4. The app is text heavy which makes the issue more visible than in RNTester for instance.
### Before
<img width="854" alt="Screenshot 2024-05-17 at 4 19 46 PM" src="https://github.com/facebook/react-native/assets/849905/5e3cc7ad-299c-4814-ab4a-031c0e677b12">
It turns out that `[NSMutableString stringWithString:@""]` is initialized in every call of the recursion even though most of the time it's only used to check the length at the end and return `nil`.
My change only initialize the mutable string if it's going to be used. I applied the same logic to the equivalent Fabric component. It's a small change that improved the accessibility label generation by 60ms in my case.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [CHANGED] - Reduce memory allocations when computing accessibilityLabel
Pull Request resolved: https://github.com/facebook/react-native/pull/44605
Test Plan:
Running the same measurements after the change, computing the accessibility label is not the heaviest stack trace anymore. And the line by line tracing shows that `[NSMutableString stringWithString:@""]` impact has been significantly reduced.
### After
<img width="769" alt="Screenshot 2024-05-17 at 4 53 04 PM" src="https://github.com/facebook/react-native/assets/849905/1ad638ac-ba7e-4dca-ac77-10df5d2dad49">
I have been using this change in production thanks to a patch-package and it effectively improved the performances when navigating between screens.
I also tested in RNTester with and without Fabric. For both architectures, I made sure the return value of `RCTRecursiveAccessibilityLabel`.
Interestingly, when there is no label, the Fabric implementation returns an empty string while the `RCTView.m` returns `nil`.
I'm open to align both implementations to return `nil` if you believe there is no underlying reason requiring the Fabric implementation to return an empty string.
Reviewed By: cipolleschi
Differential Revision: D67620818
Pulled By: javache
fbshipit-source-id: 1a6937075a5ff5a9ad03fbbf910d64b3884c0fe0
Summary:
I noticed that `AppDelegate` subscribers listening for `applicationDidEnterBackground` events in Expo projects (as documented [here](https://github.com/expo/expo/blob/238b6f57e459dd2c0b13ee158f0af709fe922460/docs/pages/modules/appdelegate-subscribers.mdx?plain=1#L56) aren't working as expected anymore.
While investigating, I discovered that the events aren't reaching the `ExpoAppDelegate` implementation ([source](https://github.com/expo/expo/blob/71f2c55ff3f11e43ab43761bb5cece2e48eae0bf/packages/expo-modules-core/ios/AppDelegates/ExpoAppDelegate.swift#L61)) because the `RCTAppDelegate` implementation of `applicationDidEnterBackground` interrupts the event chain. This appears to be affecting some legitimate use cases.
I believe we could improve this by removing the current implementation, but I'd love to hear your thoughts on this approach. I might be missing some context about why this implementation was originally needed, so any insights would be greatly appreciated!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
Pull Request resolved: https://github.com/facebook/react-native/pull/48376
Test Plan: Ran a local test after change
Reviewed By: javache
Differential Revision: D67621557
Pulled By: cipolleschi
fbshipit-source-id: 2d73711372deba867bd616c79ef4d00c79aa86d5
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/48363
jq is already installed on M1 machines on GithubActions. There is no need to install it again and this is outputting a warning in CI:
{F1974100065}
## Changelog:
[Internal] - Do not install jq as it is already installed
Reviewed By: blakef
Differential Revision: D67599961
fbshipit-source-id: 1f621f796b0c67ec877fc35269137537618f47ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48364
The configuration to run E2E tests on maestro has a typo that was outputting a warning in CI:
{F1974100056}
## Changelog
[Internal] - Fix typo on E2E test configuration
Reviewed By: robhogan
Differential Revision: D67599849
fbshipit-source-id: 9504f821172782e188ff524176bc4c2ec48dea97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48365
For a mistake, the local E2E test we use to test a release is still pointing to the release APK instead of using the debug apk.
This change fix that. The change has been manually applied to the release branches, for example [here](https://github.com/facebook/react-native/commit/385318bf6a83b124d9e8eb925932edff02115c85)
## Changelog
[Internal] - use Debug apk instead of release one to test the release
Reviewed By: robhogan
Differential Revision: D67599760
fbshipit-source-id: 224b5b8d8f664bb579b09ee68f1b92c0774a9b5e
Summary:
Sometimes, specific E2E tests can fail. This change tries to run specific E2E tests with retries, to compensate for their flakyness.
## Changelog:
[Internal] - Add single test retry for Android E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48324
Test Plan: GHA
Reviewed By: huntie
Differential Revision: D67396758
Pulled By: cipolleschi
fbshipit-source-id: 7d806fe7354bd9e826c591ea9628c73c3b258fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48327
This PR introduces necessary changes to let React Native uses latest version of static Hermes.
## Explanation
### Part 1
```cmake
append("/d2UndefIntOverflow-" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
```
It seems like this flag doesn’t exist anymore in the MSVC 16 compiler.
CI logs - https://github.com/piaskowyk/react-native/actions/runs/11815096269/job/32915591004
```
fatal error C1007: unrecognized flag '-UndefIntOverflow-' in 'p2'
```
### Part 2
```cmake
if("${CMAKE_CXX_COMPILER_ID}" MATCHES "MSVC")
# MSVC needs C++20
set(CMAKE_CXX_STANDARD 20)
else()
set(CMAKE_CXX_STANDARD 17)
endif()
```
Some of the new syntax in static Hermes requires the newer C++ standard on MSVC.
### Part 3
```cmake
# Changes in lib/CMakeLists.txt
```
These updates are necessary to successfully build the Hermes Framework for iOS.
### Part 4
```diff
namespace hermes {
namespace hbc {
namespace {
class BytecodeSerializer {
- friend void visitBytecodeSegmentsInOrder<BytecodeSerializer>(
+ friend void hermes::hbc::visitBytecodeSegmentsInOrder<BytecodeSerializer>(
```
Due to additional additional anonymous namespace, the MSVC wasn't able to recognise proper symbol without explicite definition.
X-link: https://github.com/facebook/hermes/pull/1566
Test Plan: Build RNTester app from here - https://github.com/piaskowyk/react-native/tree/%40piaskowyk/build-static-hermes
Reviewed By: tmikov, cipolleschi
Differential Revision: D67316013
Pulled By: neildhar
fbshipit-source-id: cf03850f94a75acd827b68794700a8f143a90e09
Summary:
Follow up from https://github.com/facebook/react-native/issues/48271 and https://github.com/facebook/react-native/issues/48254, I noticed that the Modal component also doesn't map the `resource-id` from the `testID` on Android. This PR addresses that.
## Changelog:
[ANDROID] [FIXED] - Modal: Setting `resource-id` from `testID` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/48313
Test Plan:
Alternatively do:
```
$ adb shell uiautomator dump
UI hierchary dumped to: /sdcard/window_dump.xml
$ adb pull /sdcard/window_dump.xml
/sdcard/window_dump.xml: 1 file pulled, 0 skipped. 1.1 MB/s (3505 bytes in 0.003s)
```
and check in XML: ` resource-id="playground-modal" class="android.view.ViewGroup" `
-------
Using Appium, check that the `testID` prop passed from JS is mapped as `resource-id` in the rendered view group of the Modal.
<details>
<summary>Example of the code implementation in the RNTester Playground:</summary>
```tsx
function Playground() {
const [modalVisible, setModalVisible] = React.useState(false);
return (
<>
<Modal
visible={modalVisible}
testID="playground-modal">
<Text testID="inner-text-test-id">Hello World!</Text>
</Modal>
<Button
title="Open Modal"
onPress={() => {
setModalVisible(true);
}}
/>
</>
);
}
```
</details>
<details>
<summary>Output in Appium Inspector:</summary>
<img width="913" alt="image" src="https://github.com/user-attachments/assets/514ae2b3-35a8-4a1a-8efc-1ca6bd73f189" />
</details>
Reviewed By: javache
Differential Revision: D67369350
Pulled By: alanleedev
fbshipit-source-id: a799ad5b974895a39d9287e3d76d1139a6ef6a83
Summary:
If 3rd party libs are using `inputAccessoryView` - the current code can easily break it. Whenever props gets changed we call `setDefaultInputAccessoryView` which will simply overwrite the current `inputAccessoryView` (which is highly undesirable).
The same fix on paper was made ~7 years ago: https://github.com/facebook/react-native/commit/bf3698323d81508fc77174df2b1ffe5fb03224e7
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fixed problem with accessory view & 3rd party libs
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/48339
Test Plan: Make sure `inputAccessoryView` functionality works as before
Reviewed By: javache
Differential Revision: D67451188
Pulled By: cipolleschi
fbshipit-source-id: bc3fa82ae15f8acedfd0b4e17bdea69cbd8c8a8d
Summary:
All newly generated react native apps are still showing warnings to use react in the jsx scope. That is not needed anymore as of react 18 with built-in jsx transform plugin.
Reproduction: https://github.com/matinzd/react-in-jsx-warning-repro
Run `npm run lint` in this repo.
## Changelog:
[GENERAL] [FIXED] - Disable `react-in-jsx-scope` rule in eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/46587
Test Plan: Initiate a new template with community CLI and you should not see this warning anymore.
Reviewed By: christophpurrer
Differential Revision: D67394923
Pulled By: cipolleschi
fbshipit-source-id: cfe8e44e33e1b3ae9fe17ca56dd3c7258b7bff69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48250
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D66839601
fbshipit-source-id: dfba4aab6d73a2fd805ad2761a49c23612c28ccd
Alex Hunt
Ruslan Shestopalyuk
Riccardo Cipolleschi
zhongwuzw
Nicola Corti
TobiasH
Oskar Kwaśniewski
timbocole
Peter Abbondanzo
Rob Hogan
Maddie Lord
BleemIs42
Gaspard Viot
Alex Toudic
Mateo Guzmán
Ramanpreet Nara
Intl Scheduler
Sam Zhou
David Vacca
Krzysztof Piaskowy
Thomas Nardone
Pieter De Baets
kirillzyusko
Matin Zadeh Dolatabad
Pieter De Baets
Richard Barnes
