Summary:
react-native-windows builds treat a lot of c++ compiler warnings as errors. Including ones that cause value truncation when assigning `size_t` values to an `int`.
This fixes the compiler warning, by using `size_t` as the type for `i`, which matches `size`. I then modified the loop to avoid the value underflow that occurs when decrementing an unsigned zero value.
## Changelog
[Internal] [Changed] - Fix compiler warnings around mixing int and size_t usage in unsafe ways
Pull Request resolved: https://github.com/facebook/react-native/pull/34889
Test Plan: This code change was made in react-native-windows when integrating latest react-native changes. -- our fabric implementation was able to run through this code without any issues.
Reviewed By: mdvacca
Differential Revision: D40158306
Pulled By: rozele
fbshipit-source-id: b6858cb953635b37fd63a88ed1a372eb3dc394f7
Summary:
changelog: [internal]
RuntimeScheduler's callbacks previously did not pass down argument `didUserCallbackTimeout`. This was intentionally left out because React team intended to remove it. But, as it turns out, it was not removed and it is needed for Offscreen to not enter infinite render loop. In React, it is used here: https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L1022-L1028
Reviewed By: ryancat
Differential Revision: D40060377
fbshipit-source-id: c45719fbbd0275ab2bcf9a2bbf0191aaa96010cc
Summary:
Fixes Xcode release builds when Hermes is enabled.
The Hermes debugger is loaded by the Hermes executor only if HERMES_ENABLE_DEBUGGER is defined. The hermes-engine Pod would set `HERMES_ENABLE_DEBUGGER=0` in release builds, but of course this would satisfy the HERMES_ENABLE_DEBUGGER ifdef check, leading to build time issues due to missing `hermes::debugger` symbols.
Now, both the `hermes-engine` and `React-hermes` pods only set `HERMES_ENABLE_DEBUGGER=1` in debug builds. No gcc preprocessor definition is added by these pods in release builds.
Changelog:
[iOS] [Changed] - Do not load Hermes inspector in release builds
Reviewed By: cipolleschi
Differential Revision: D40077503
fbshipit-source-id: dd9ce148e8521fc4e43e47e90f29ba8f7c9b7e4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
This PR renames ` hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`, moves it to `packages/hermes-inspector-msggen` and makes the package private as part of RFC480.
Related to https://github.com/facebook/react-native/issues/34692
## Changelog
[General] [Changed] - Move and rename `hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`
Pull Request resolved: https://github.com/facebook/react-native/pull/34850
Test Plan: run `sh ReactCommon/hermes/inspector/tools/run_msggen`
Reviewed By: mattbfb
Differential Revision: D40060406
Pulled By: cortinico
fbshipit-source-id: e018fd88e8374a69fbd8737fbb9abe7565d4a003
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
When building and using C # libraries,
EntryPointNotFoundException thrown from YGInteropSetLogger.
so, I added YOGA_EXPORT on YGInteropSetLogger.
X-link: https://github.com/facebook/yoga/pull/960
Reviewed By: yungsters
Differential Revision: D40027238
Pulled By: yungsters
fbshipit-source-id: 6af584a16e66a31c91374a1bb64434888762e3c8
Summary:
When I use libyogacore.so in other programming languages, it crash with message as
> Could not obtain symbol from the library: dlsym(0x20b84d220, YGConfigIsExperimentalFeatureEnabled): symbol not found
This function is defined as `WIN_EXPORT bool YGConfigIsExperimentalFeatureEnabled` in yoga.h, but is not defined using `YOGA_EXPORT` in yoga.cpp.
X-link: https://github.com/facebook/yoga/pull/1127
Reviewed By: yungsters
Differential Revision: D40024450
Pulled By: yungsters
fbshipit-source-id: f6f01eadccb13d593c68300059e96f4b0bbc9fb6
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
This removes the old way of consuming `libfolly_runtime.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Moreover, I've exposed a `folly-flags.cmake` file which can be used by libraries
to know which lists of flags they need to use for Folly.
Changelog:
[Internal] [Changed] - Move `folly_runtime` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39928571
fbshipit-source-id: 4864c37813ec681a6a464c97de6dfc078f5553f1
Summary: We have decided not to go forward yet with using flexlayout in react-native. This change removes it for now.
Reviewed By: JTYim
Differential Revision: D39822037
fbshipit-source-id: 726e8657b62e6b4e55e5f72be3ca5539d317348e
Summary:
Cleans up the dependencies in `ReactCommon/hermes/inspector/tools/msggen` by
- Analyzing and removing any dependencies that are never referenced.
- Upgrading all dependencies to their latest versions (by deleting `yarn.lock` and re-running `yarn`).
- I only upgraded Babel dependencies to the same version used by the rest of `react-native`.
Notably, this resolves 13 vulnerabilities reported by Dependabot.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34782
Test Plan:
Ran the following successfully:
```
$ cd ReactCommon/hermes/inspector/tools/msggen
$ yarn
$ yarn test
$ yarn build
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D39804478
fbshipit-source-id: c673e80b64fcf49c3f903c5d7f0a68c77d63a4bd
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Upgrades all of our JavaScript tooling to use `yargs@^17.5.1`.
Of all [release notes](https://github.com/yargs/yargs/releases), these are the major version notes:
- [v17.0.0](https://github.com/yargs/yargs/releases/tag/v17.0.0)
- [v16.0.0](https://github.com/yargs/yargs/releases/tag/v16.0.0)
A cursory inspection suggests that these breaking changes are unlikely to seriously impact our use cases (or can be fixed forward).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D39550338
fbshipit-source-id: 5b2c5265f8c7a95ab0cc9bab62873f9e4355f32f
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Changelog: [Internal] Remove unused RuntimeExecutor from UIManagerBinding constructor
Since [UIManager is the class that has a reference to RuntimeExecutor](https://github.com/facebook/react-native/blob/ce50c43986bae05ad62552be46f4d5bb4a46f097/ReactCommon/react/renderer/uimanager/UIManager.h#L35-L36), there's no reason for `UIManagerBinding` to own a reference to RuntimeExecutor too.
The purpose of `UIManagerBinding` is to bind the Fabric `std::shared_ptr<UIManager>` in C++ to `global.nativeFabricUIManager` in JS.
Doing this cleanup to make the next diff easier.
Reviewed By: sammy-SC
Differential Revision: D39490927
fbshipit-source-id: 4c393dccc6985bef44e3b0afc32b9f79bea25f80
Summary:
We already support attaching-on-reload when a debugger was a previously connected, and this connection logic seems to slow down app startup by 2 seconds in debug mode when running on device.
Changelog:
[Internal][Removed]
Reviewed By: jpporto
Differential Revision: D39272704
fbshipit-source-id: deb8651798cb9a13b81e1703920d3f9bd58869d2
Summary:
A previous change made the RuntimeAdapter contain a HermesRuntime (as opposed to an arbitrary JSI Runtime).
Now that it's known to be a HermesRuntime, expose that type information to the Inspector, so a runtime type check can be skipped (which is failing in some builds, despite the concrete type being what's expected).
Changelog: [internal]
Reviewed By: neildhar
Differential Revision: D39429109
fbshipit-source-id: ad5ae0604ac208da2002fd37e38d24319b45aebd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5