Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41162
"The C++ standard forbids containers of const elements because allocator<const T> is ill-formed."
We have a few other callsites for std::vector<const ...>, but the const values are always const pointers, which I guess are okay?
Suffice to say, this doesn't compile with Microsoft STL headers unless you remove const.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D50563174
fbshipit-source-id: 96053baedc41237d8d27a1e01ac94ce5abd6c768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41136
Changelog: [iOS][Breaking] You cannot call methodQueue on RCTHTTPRequestHandler
the `synthesize methodQueue` API is confusing, it looks like an API only for use within native module implementation, but it's actually needed to create a selector that corresponds to the property declared in the `RCTBridgeModule` public protocol.
no one is using the `methodQueue` on `RCTHTTPRequestHandler`, so let's get rid of the public access to it.
Reviewed By: javache, cipolleschi
Differential Revision: D50525900
fbshipit-source-id: f83738491d0eadc71a6dc3194ee16fe7c8748263
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41090
This propagates to enable the use of microtasks in the React reconciler, Runtime Scheduler and Hermes.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50177355
fbshipit-source-id: 6cf23cf72b63d19f50453d3e4cc4ac1b056dbd92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41084
Adds support for executing microtasks in `RuntimeScheduler`, the same way we did in `JSIExecutor` before (removed in D49536251 / https://github.com/facebook/react-native/pull/40870) but now after each actual task in the scheduler.
When we use microtasks in the scheduler, we ignore calls to execute expired tasks (which was used to call "React Native microtasks" that we had before). Those should now be regular microtasks in the runtime.
This is gated behind a feature flag until we've tested this broadly.
This is going to be tested in Hermes but we need to add support for microtasks in JSC (which has a no-op in its JSI interface).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49536262
fbshipit-source-id: 8f7ce54c266d1f25312a641abc4ef073d019281f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41082
We're testing a method to access `ReactNativeConfig` without a dependency on native modules, so we can access it before that infra is initialized in places like Hermes or RuntimeScheduler.
When we're in that variant, this passes the configuration to Hermes so we can use it to set flags in the runtime (like enabling microtasks in D50177355).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50450488
fbshipit-source-id: 77f0369f93bb7175c569d51b0569669552a13acf
Summary:
When creating the react root for Logbox, we do not pass the concurrentRoot option leading to a warning because it is using Fabric.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50558855
fbshipit-source-id: ed4399293ca4001bf4e0e059a0eb73481bcf4832
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41158
This feature flag was just a killswitch for OSS. As we don't need it anymore, I'm removing it.
I've also discussed with Expo so they remove any usages of this in their codebase.
Changelog:
[Internal] [Changed] - Remove unnecessary unstable_useRuntimeSchedulerAlways Feature Flag
Reviewed By: rubennorte
Differential Revision: D50554334
fbshipit-source-id: b2346654ad543c1350f2f2cae078900abf39d41c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39540
This simplifies the use of Codegen when creating dev builds of `rn-tester` in the monorepo. It now runs from source for this internal scenario, and this package is now built using the shared monorepo build setup.
Changes:
- Migrate `packages/react-native-codegen` to the shared `yarn build` setup.
- Update package to use `"exports"` field and wrap entry point modules with `babel-register` (NOTE: This is only required for each entry point internally used in the monorepo).
- Fixup small Flow syntax quirks that fail under `hermes-parser`.
- Remove `BuildCodegenCLITask` task from Android build.
- Remove Codegen `build.sh` call from iOS build, use `require.resolve` for `combine-js-to-schema-cli.js` entry point.
Externally significant FYIs:
- `react-native/codegen` is converted to use the `"exports"` field — it should export all `.js` files, as before.
- `codegenPath` is now ignored and marked as deprecated on `ReactExtensions.kt`.
NOTE: TypeScript auto-generation is not yet enabled on this package, since it uses CommonJS `module.exports` syntax (unsupported by `flow-api-translator`).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D49370200
fbshipit-source-id: 992913155169912ea1a3cb24cb26efbd3f783058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41159
Changelog: [Internal]
Cleanup from D48966244. The deprecated `jsinspector` files are no longer used by any code in either fbsource or `react-native`.
Reviewed By: hoxyq
Differential Revision: D50530796
fbshipit-source-id: b539b097cb6caf6c50a482fa93bf5d7886e76e52
Summary:
E2E tests in OSS are expensive and flaky.
They already prevented some broken changes to land on main, but as of today:
- they are always green, so they are not bloking
- nobody is looking at the reporting job
- the reporting job takes a lot of time to run and prevent other useful signals to be available soon
- it is expensive
So we decide to disable them for the time being, while we iterate on those with Callstack and MSFT.
## Changelog:
[Internal] - Disable E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/41153
Test Plan: CircleCI stays green
Reviewed By: cortinico
Differential Revision: D50552818
Pulled By: cipolleschi
fbshipit-source-id: 7160a8074492c3c9a55485d8a17a6883eb4b35b5
Summary:
This is a small fix to update line number pointing to `fabric_enabled` line number
## Changelog
[Internal] [Fixed] - Update line number in RNTester README
Pull Request resolved: https://github.com/facebook/react-native/pull/41145
Test Plan: Not needed
Reviewed By: rshest
Differential Revision: D50551044
Pulled By: cipolleschi
fbshipit-source-id: bed88c54f3b2718ca4cdb08e66fed2d7e4cac7ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41081
It turns out that Bridgeless for RN-Tester release is still broken.
This fixes it by making sure we actually `DoNotStrip` the missing constructor
Changelog:
[Android] [Fixed] - Fix crash with `java.lang.NoSuchMethodError` for Bridgeless
Reviewed By: RSNara
Differential Revision: D50455967
fbshipit-source-id: eae971fceeb863d8a400e9de1d2467637d59d2b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41152
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, and on D49954920, this diff passes stable, unique *logical device IDs* to the debugger connection infrastructure from Android and iOS.
See D49954920 for the precise stability and uniqueness requirements that these IDs meet.
Changelog:
[Changed][General] - Automatically reconnect to an existing debugger session on relaunching the app
Reviewed By: huntie
Differential Revision: D49954919
fbshipit-source-id: d4d918f0cbfd9df426e888845817e00410efb9d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41154
Pull Request resolved: https://github.com/facebook/react-native/pull/41080
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, adds support for passing a `device=...` argument to `/open-debugger` for more precise targeting.
Changelog: [Internal]
---
## Note on what "device" means in this context
In `dev-middleware` / `inspector-proxy`, "device" is something of a misnomer. It refers to a *logical device* containing one or more *pages*. In React Native, each app process forms its own logical device in which individual VMs register themselves as pages. An instance of `inspector-proxy` connects one or more *debuggers* (frontends) to one or more logical devices (one frontend to one page on one device).
The intent of the logical device ID is to help with target discovery and especially *re*discovery - to reduce the number of times users need to explicitly close and restart the debugger frontend (e.g. after an app crash).
If provided, the logical device ID:
1. SHOULD be stable for the current combination of physical device (or emulator instance) and app.
2. SHOULD be stable across installs/launches of the same app on the same device (or emulator instance), though it MAY be user-resettable (so as to not require any special privacy permissions).
3. MUST be unique across different apps on the same physical device (or emulator).
4. MUST be unique across physical devices (or emulators).
5. MUST be unique for each concurrent *instance* of the same app on the same physical device (or emulator).
NOTE: The uniqueness requirements are stronger (MUST) than the stability requirements (SHOULD). In particular, on platforms that allow multiple instances of the same app to run concurrently, requirements 1 and/or 2 MAY be violated in order to meet requirement 5. This will be relevant, for example, on desktop platforms.
In an upcoming diff, we will pass device IDs meeting these criteria from both iOS and Android.
Reviewed By: huntie, blakef
Differential Revision: D49954920
fbshipit-source-id: 45f2b50765dece34cbb93fa32abcdf3b0522391c
Summary:
App can be submitted to the app store by using Xcode 14.1 as min Xcode version.
Right now we are testing everything against the latests Xcode, but it would be good to have some tests to check that we don't break the flow for people stuck on older Xcodes.
We already had issues like these in the past, unfortunately.
Plus, we are making some changes using C++20 which we don't know whether they are properly supported by older versions of Xcode.
This change should give us confidence on those changes too.
## Changelog:
[Internal] - Use Xcode 14.1 for some tests
Pull Request resolved: https://github.com/facebook/react-native/pull/39602
Test Plan: CircleCI is green
Reviewed By: NickGerleman
Differential Revision: D49540292
Pulled By: cipolleschi
fbshipit-source-id: 71c07293598fd5b1f73f6d7d9425f385aa12fc4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41113
changelog: [internal]
We must prevent VirtualizedList._onContentSizeChange from being triggered by a conflicting bubbling onContentSizeChange event.
For TextInput, we change the event onContentSizeChange from bubbling to direct (https://github.com/facebook/react-native/commit/744fb4a0d23d15a40cd591e31f6c0f6cb3a7f06b). To make this safer, we need to filter out any `onContentSizeChange` event since we can't control 3rd party components from dispatching onContentSizeChange as bubbling event.
Reviewed By: NickGerleman
Differential Revision: D50451232
fbshipit-source-id: b7a446e4efc9c45024d37f35cb53f2fcbb28799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41114
changelog: [internal]
MountItemDispatcher integrates with FabricUIManager in a non-obvious ways. This diff documents some of that.
Reviewed By: NickGerleman
Differential Revision: D50494929
fbshipit-source-id: ed3c1748765ca4590035be20f045ecfb14af86c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41043
Changelog: [Internal]
in this change, we create an config pipeline to set `_enableSharedModuleQueue` in TMM
Reviewed By: cipolleschi
Differential Revision: D50398636
fbshipit-source-id: cd8c210ad2ae4774ceb10130a8b80e500d17986a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41042
Changelog: [Internal]
currently, each native module creates a new module queue if `methodQueue` is not overridden in the native module.
we want to see if we can use a single execution queue for a few reasons:
- parity with android's queue model
- performance: creating so many queues... for what? the overhead of this feels like it exceeds any potential benefit
- set us up to remove the assocs from the module to the method queue, which will allow us to deprecate `synthesize methodQueue` and `-(dispatch_queue_t)moduleQueue` API.
in this QE, we just start with replacing the KVO assoc'd queue with the shared module queue.
Reviewed By: cipolleschi
Differential Revision: D50398635
fbshipit-source-id: 0b194a5ae5269e843c7c537a973ee1d345ce1df4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41086
In this diff I'm fixing the lookup of ReactModuleInfoProvider instance for CoreReactPackage. It is searching for the wrong class.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338304
fbshipit-source-id: 840d1d018cc0f9df8a64fd09a851d8a87f5a1f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41083
All callsites for `useImperativeHandle` have been removed, so we can also remove the import from react.
## Changelog
[General][Internal]
Reviewed By: mogers
Differential Revision: D50457268
fbshipit-source-id: befa08cf7173a8d02800fa2447dbcd8a9ce874de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41039
## Changelog:
[iOS][Breaking] - repeatInterval is deprecated in PushNotificationIOS. Use fireDate and the new fireIntervalSeconds.
Reviewed By: philIip
Differential Revision: D50277316
fbshipit-source-id: ddcc2d2fc9d89d2bacac296848109e98c95c0107
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41118
Updates the release process and guidance for `debugger-frontend`, now that the source [facebookexperimental/rn-chrome-devtools-frontend](https://github.com/facebookexperimental/rn-chrome-devtools-frontend) repo is published.
The `sync-and-build` script now requires a `--branch` argument, allowing us to match release branches across repos for hotfixes (e.g. `0.73-stable`).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D50496327
fbshipit-source-id: 671fd1581e23032eec0a419a6e50dac6c76feeb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39163
Changelog: [Internal]
Flow knows about `util.parseArgs` now and has [really nice types for it](https://github.com/facebook/flow/commit/dc5c06a7cbf4b326bd1582b91c5cd0ed65a705bb), so let's update the type definitions for the `pkgjs/parseargs` shim to use those. The updated types use conditional and mapped types to generate a more precise return type for `parseArgs`, based directly on the provided config object.
Reviewed By: huntie
Differential Revision: D48683091
fbshipit-source-id: c0c8fe655a595e6f2f5cf1d4fc1ff0163ed3635f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41126
Long term, we'll want to flow check React Native desktop code, but in the near term, we can side step flow issues entirely by denylisting the desktop forked files in .flowconfig [ignore]. In fact, we don't do any flow checks on react-native desktop today 😬.
For the most part, the .macos.js and .windows.js forked files will be trivial changes to existing modules from react-native-github, and they will be kept in sync in an automated way, so there's an argument that the value of flow checks on these files is pretty limited.
However, at least until flow supports sub-directory multi-platform extensions and interface type hierarchies, we'll need to have entirely separate .flowconfigs for mobile and desktop (as desktop adds APIs to react-native mobile for things like keyboard input and navigation on arbitrary views).
These desktop .flowconfigs will come in a later diff.
## Changelog
[General][Internal]
Reviewed By: shwanton
Differential Revision: D50426512
fbshipit-source-id: f174268468056d510be0993ef619469c9cee3b4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39480
Changelog:
[Internal] - Separate the time series data and renderer logic from performance monitor overlay so that it can be swapped later to C++ for cross-platform support.
Reviewed By: rshest
Differential Revision: D49321748
fbshipit-source-id: fbb781ef710b134130bfd80dada00748e73d5f24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41087
CoreModulesPackage is not being used outside of its package (neither in OSS or at Meta), I'm reducing its visibiity to package.
If you are using this class, please contact us and we will consider increasing visibiity again.
bypass-github-export-checks
changelog: [Android][Breaking] Reduce visibility of CoreModulesPackage class
Reviewed By: christophpurrer
Differential Revision: D50338546
fbshipit-source-id: 3f0ce4dd22ddfa6743760ad378e7c6e45ab58127
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41088
This was probably caused by a copy paste, I'm fixing the log message to describe the proper class.
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338296
fbshipit-source-id: 28657009ae7f9467d29eecd9b68c1f9541696350
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41014
DebugCorePackage is only used from com.facebook.react, there are no interesting usages internally at Meta or in OSS, so I'm reducing the visibility to package.
bypass-github-export-checks
changelog: [Android][Breaking] Reducing visibility of DebugCorePackage
Reviewed By: christophpurrer
Differential Revision: D50338294
fbshipit-source-id: db9b3be3b1899733a2f9d5f1cbeb314c2d350b57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41072
As part of the new architecture rollout, we want to simplify our set of supported configurations. Right now it is possible to use Fabric / new architecture without using concurrent root, which prevents us from bringing the new concurrent capabilities to these applications and holds back React renderer code.
Changelog: [Deprecated] Using the new architecture without concurrent root will soon not be supported.
Reviewed By: rubennorte, sammy-SC
Differential Revision: D50425540
fbshipit-source-id: 1ec4c8202074e6ea98178f1a07311fda35b1951b
Summary:
In one of the latests commits on main, Hermes failed somehow to build dSYMs in some slices.
However, the slices were cached (so the cache is poisoned) and the overall process failed.
With this change, we aim to make the slice's build process fail if the dSYM or the actual framework is not built properly, before caching, so they are not poisoned
## Changelog:
[Internal] - Fail the build if dSYM or hermes.frameworks are not built
Pull Request resolved: https://github.com/facebook/react-native/pull/41076
Test Plan: CircleCI is green
Reviewed By: huntie
Differential Revision: D50453598
Pulled By: cipolleschi
fbshipit-source-id: 06bf16ef1472bd9bc9825977b817445272477a10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41048
Reapplies D49792717
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Deprecated] AsyncCallback replaces RAIICallbackWrapperDestroyer as a safer way to manage jsi::Function memory ownership.
Reviewed By: rshest
Differential Revision: D50319914
fbshipit-source-id: e038813cad85c47be1f004bc2ea1fdaf0eee9094
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41061
changelog: [internal]
Method `dispatchCommandMountItem` only calls `addViewCommandMountItem` without adding anything on top of it. The name is inaccurate because it doesn't dispatch mount item, it queues it.
Let's remove one of them to simplify the API.
Reviewed By: javache
Differential Revision: D50408576
fbshipit-source-id: 3a4871c38e7b081a5e27aba211d61254075e76cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41060
changelog: [internal]
The return value is never consumed, let's remove it.
Reviewed By: rubennorte
Differential Revision: D50407732
fbshipit-source-id: 8a363d874b4e1eb7852a9fefb3b511f66d3fdbe9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39943
When the user attaches a debugger, and the app moves to the background the debugging session persists. This
sends a CDP console.info so the debugging user is aware of the app's state. It is an easy state to get into
when debugging on multiple emulators.
Changelog: [iOS][Added] - Add console.log notification in DevTools if app transitions between back/foreground.
Reviewed By: dmytrorykun
Differential Revision: D49956535
fbshipit-source-id: 29e1aba9c4eaeba072fe04f2b932a3e04c96d081
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41055
This should fix the issue highlighted in [this comment](https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7271155).
Basically, before the fix, we were not supporting flavours correctly, as we assumed that only Debug and Release were available.
With this change, we infer whether we have to fetch Hermes for Debug or Release based on the actual flags that are passed. In this way, the users can customize their app's flavors more freely.
## Changelog:
[Internal] - Support multiple flavors when downloading Hermes
Reviewed By: huntie
Differential Revision: D50408381
fbshipit-source-id: 6990218b286b4dd823323bc63de90279efc9e74e
Summary:
X-link: https://github.com/facebook/yoga/pull/1431
Pull Request resolved: https://github.com/facebook/react-native/pull/41041
The last of the row-reverse issues hurray!
The position insets were broken with row-reverse since we were using the main-start/main-end edges to inset from and NOT the inline-start/inline-end edges as we should. This made it so that inset in left and right were swapped and same with top and bottom (with column-reverse). The solution here is the same as the previous ones were we are migrating to using inline-start/end as the leading/trailing edge now.
Reviewed By: NickGerleman
Differential Revision: D50390543
fbshipit-source-id: b714deab8489fbe11f7f6db21e4aad3b3aa314b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41044
The reference Clang/GCC build has a pretty strict set of warnings enabled. The reference MSVC build has less strict warnings, which can be a problem for MSVC users building at higher warning levels (e.g. React Native for Windows in OSS uses `/W4` as its baseline warning level).
This bumps up the MSVC warning level to `/W4`, since we are nearly clean already.
There are some limitations. E.g. we don't test binary with MSVC (some issues I didn't work out), and only test building statically linked. But but we do have a minimal C benchmark we compile with MSVC.
X-link: https://github.com/facebook/yoga/pull/1432
Test Plan: GitHub Actions running benchmark MSVC build.
Reviewed By: yungsters
Differential Revision: D50398443
Pulled By: NickGerleman
fbshipit-source-id: 6616034d79b1a308b32d5d3387bae70f40b7b5ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41067
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Added parsing support for `as` expressions as well as `renders*` and renders?`.
- Updated internal prettier version to `3.0.3`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D50395762
fbshipit-source-id: 8a9131ea1b0683e79c7bc74b4df9deafac7450f9
Arushi Kesarwani
Eric Rozell
Phillip Pan
Rubén Norte
Pieter De Baets
Gijs Weterings
Nicola Corti
Alex Hunt
Fabrizio Cucci
Moti Zilberman
Samuel Susla
Riccardo Cipolleschi
Oskar Kwaśniewski
Jane Li
David Vacca
Ingrid Wang
Xin Chen
Dimitar Nestorov
Blake Friedman
Riccardo Cipolleschi
Sam Zhou
Joe Vilches
Nick Gerleman
Pieter Vanderwerff
Alex Taylor (alta)
Thomas Nardone