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:
Pull Request resolved: https://github.com/facebook/react-native/pull/39367
Updates React Native to use the new CDP handler provided by the Hermes engine instead of the legacy one (`Connection.cpp`) built into React Native. The new Hermes CDP handler has a simpler & safer design, new features (e.g. `console.log` buffering) and is under active development by the Hermes team.
NOTE: Both the legacy and modern handlers are Hermes-specific. In future work, React Native will *wrap* the modern Hermes handler in an engine-agnostic CDP layer implementing additional functionality and managing the lifecycle of debugging sessions more correctly. This diff is the first step of this larger migration.
Changelog: [General][Changed] Use new Hermes CDP handler implementation for debugging
Reviewed By: cipolleschi
Differential Revision: D48783980
fbshipit-source-id: 4d2ca3fa04e96e92a38d82c90737cb660ba56655
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39289
"tickleJS" is a function in RN Hermes Debugger, we need to implement it for Bridgeless for feature correctness and keep parity with Bridge.
Changelog:
[Internal] - Implement "tickleJS" for Hermes in Bridgeless mode
### Summary of discussion:
**Goal of this diff**:
Implement tickleJS for Hermes debugger with Bridgeless, here is Bridge's implementation
https://www.internalfb.com/code/fbsource/[7058fb4dae4f]/xplat/ReactNative/react/jsi/HermesExecutorFactory.cpp?lines=45-57
**The key problem to solve:**
As you can see from Bridge's implementation, we need to dispatch the js call of "__tickleJs" to dedicated JS thread queue for thread safety, and it did cause a crash for me locally without dispatching to JS thread queue (see P818439922).
For Bridgeless passing the JS message queue directly works, but then we would naturally want ask if RuntimeExecutor/RuntimeScheduler is a better choice because: 1, It should also work 2, It's the common way to run js code in native with Bridgeless 3, Can avoid potential race condition caused by dispatching to JS message queue directly 4, We're planning to expose RuntimeExecutor/RuntimeScheduler or a similar abstraction anyway. So the argument here is which solution should we take?
**Why we decide to move forward with the JS msq solution?**
- Time constraint: we need to ship this before 0.73
- After discussion there hasn't been any major concern over dispatching to JS msq directly so far
- How to expose RuntimeExecutor/RuntimeScheduler is a bigger topic which need further research, we don't want to hold this diff for it
For detailed discussion see the post https://fb.workplace.com/groups/react.technologies.discussions/permalink/3615044702060575/
Reviewed By: javache
Differential Revision: D48952581
fbshipit-source-id: 3dfb05d35c422f3fd6a420e265e4efe8fa13f057
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/39253
X-link: https://github.com/facebook/hermes/pull/1112
Changelog: [Internal]
Forks `ReactCommon/hermes/inspector` → `ReactCommon/hermes/inspector-modern`. More changes to `inspector-modern` will come in subsequent diffs.
The Gradle, CocoaPods and Buck builds of React Native have been updated to use `inspector-modern` everywhere. The code in `ReactCommon/hermes/inspector` is thus **deprecated** and unused in the open source build, and will be deleted in an upcoming diff (likely before the 0.73 cut).
NOTE: The reason we're not immediately deleting `ReactCommon/hermes/inspector` is that there are a handful of references to it in Meta's internal monorepo (*outside of React Native*) that we are in the process of migrating away. Once we've deleted the existing `ReactCommon/hermes/inspector`, we *may* rename `inspector-modern` back to `inspector`.
Reviewed By: blakef
Differential Revision: D48897203
fbshipit-source-id: 13682747d280a3231b7f6bce560f25ad174304e9
Summary:
(reland of D48761722)
Pull Request resolved: https://github.com/facebook/react-native/pull/39217
React Native uses an inconsistent mix of "west const" and "east const". E.g. `const auto &` in 74 files, but `auto const &` in 60. Sometimes they are mixed from one line to the next: {F1079102436}
Clang format 14 adds a QualifierAlignment option, but fbsource is still on 12, so we cannot use it in our config until the [world is updated]()https://fb.workplace.com/groups/toolchain.fndn/posts/24006558685624673/?comment_id=24009214565359085&reply_comment_id=24009455088668366. This diff just runs a local version of Clang format locally first to fix QualifierAlignment, then reformats with the fbsource version, to fix any other output differences unrelated to that. This will not continually enforce a style, but will make the world more consistent, and hopefully encourage a consistent style until we can set it.
West const seems more popular in `//xplat` so I just picked left alignment somewhat arbitrarily, but we could also maybe take a poll on this.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: shwanton
Differential Revision: D48852450
fbshipit-source-id: 1789aa0db43948169f482188cb8b5e8f0f0246b8
Rubén Norte
Nick Gerleman
Alex Hunt
Lulu Wu
Saad Najmi
Moti Zilberman
Arushi Kesarwani