Summary:
X-link: https://github.com/facebook/yoga/pull/1176
`Values` is a wrapper to story an array of YGValue's as CompactValues.
From https://github.com/facebook/yoga/issues/1174 we see a warning `Wdeprecated-copy` beacuse a user-defined copy constructor is not present, but a user-defined asignment operator is (the defaulted one). This adds an explicitly defaulted copy contructor which should silence the warning I think.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41447490
fbshipit-source-id: 8cc8f291cf12014d87cc71c4598bb84fdd6cd930
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35385
In OpenSource builds folly:: types are not always easy to consume.
With butter:: we actually allow consumers to opt-into other/non folly:: types (by providing a custom butter:: implementation).
This change adds a butter::function for that purpose.
It is especially useful for react-native-windows which prefers Mso::Functor over folly::Function.
You can use it by setting those compiler flags:
-DBUTTER_FUNCTION_OVERRIDE_INCLUDE=<functional/functor.h>
-DBUTTER_FUNCTION_OVERRIDE=Mso::Functor
std::function is no option as it is not move-only and we can't wait till 2025 > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0288r9.html
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41388193
fbshipit-source-id: 56f58b9ddc602aa4b13000031d50de5228b4a16b
Summary:
Fix linter warning when pulling in some code into AR
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D41269423
fbshipit-source-id: 4305d6c362a51e62b19b4d3590fb0823073dff9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35353
Unfortunately we have 2 different definitions of SystraceSection.h
- xplat/js/react-native-github/ReactCommon/cxxreact/SystraceSection.h
- xplat/js/react-native-github/ReactCommon/react/renderer/debug/SystraceSection.h
The first one is the Old Arch one and the second one is the New Arch one.
As we first step, we unify the implementation
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D41307049
fbshipit-source-id: a9eb854dfcf49f87ad81fd9cc8dbe51648ecd209
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35342
This is a native implementation of the JS shimmed layout-specific properties in https://github.com/facebook/react-native/pull/35316.
There is an experiment splitting the prop splitting codepath in Fabric, so this change effectively has two implementations depending on whether `enablePropIteratorSetter` is enabled.
None of these changes make sense to propagate Yoga. `inlineEnd`, etc are already mapped to `YGEdgeStart` and `YGEdgeEnd`, but RN's mapping used a different name. Then `blockStart`, `blockEnd`, map directly to existing edges in all cases since we don't support a writing mode.
On web, the last value in the style which computes the given dimension is given precedence. E.g. if "left" comes after "start" it will be chosen. Yoga stylesheets are unordered, and precedence for edges is given based on specificity (left > start > horizontal > all).
We give precedence to new renamings (e.g. start to inlineStart), but to preserve consistent behavior, we give precedence to specific edges before overwriting them with flow relative ones (e.g. marginTop has precedence over marginBlockStar).
Changelog:
[General][Added] - Add Fabric implementation of flow-relative padding and margin
Reviewed By: javache
Differential Revision: D41267765
fbshipit-source-id: 896e2ed71fe8bf83aef00b0a9d70fd20b2ce47a7
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
a lot of files were depending on Geometry even though they didn't use Vector, this will help with future modularity
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41127194
fbshipit-source-id: 024519c638a1f0df3fdbfbdd937eac84b9adee6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35146
This class is used by Fabric - but does not compile on macOS yet.
Changelog:
[iOS][Fixed] Make ManagedObjectWrapper compile on macOS
Reviewed By: javache
Differential Revision: D40839241
fbshipit-source-id: 73b93a9963db89af19529fbfd60a64f4e5aaf036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35089
Changelog:
[General][Fixed] - Back out "Add enum example to Android/iOS rn-tester TurboModule"
This broke the rn-tester adding due to an invalid flow-enum setup. Needs further investigation
Reviewed By: cipolleschi
Differential Revision: D40714320
fbshipit-source-id: 9831276762f90df0ffaca3304382fe5925009343
Summary:
There are use cases in which we want to pass a set of unique elements from C++ to JS and back. We can do this simple by re-using a plain JS array for these purposes.
Changelog:
[Internal][Added] react-native bridging > Add support for std::set
Reviewed By: cipolleschi
Differential Revision: D40668244
fbshipit-source-id: d06603440569e5f760c2859a54cf6e4232c7d97a
Summary:
Throws a JS error instead of crashing Hermes with an invariant when trying to convert a JS symbol or BigInt to a folly::dynamic value.
Changelog:
[General][Fixed] - Fixed crash when converting JS symbol to folly::dynamic
Reviewed By: javache
Differential Revision: D40444164
fbshipit-source-id: 37df8059b2eb425563f30cf1e9c0436e8d665b34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35065
Original commit changeset: ac76ea701e3d
Original Phabricator Diff: D40611860 (860b4d9144)
Open source is using BUCK 1 which does not seem to have the `oncall` directive.
Backing it out because it is breaking the external CI.
## Changelog
[internal]
Reviewed By: cortinico
Differential Revision: D40637084
fbshipit-source-id: 2be7296f859412210afe981adf500ab6540f7ee8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35064
Original commit changeset: 0fb0db845c04
Original Phabricator Diff: D40610875 (d941940b4c)
Open source is using BUCK 1 which does not seem to have the `oncall` directive.
Backing it out because it is breaking the external CI.
## Changelog
[internal]
Reviewed By: cortinico
Differential Revision: D40635873
fbshipit-source-id: 79ebd4db0972520fcca6ccb8c1725657a8ef7949
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
Add full functionality for `Symbol`s and `BigInt`s in the debugger. Note- using the [protocol monitor](https://umaar.com/dev-tips/166-protocol-monitor/) was the most reliable way of figuring out which fields exactly need to be set for these types to play nicely in DevTools. I brought up the monitor and then used the regular, standard chrome console with the functionality I wanted:
- Evaluating `Symbol` and `BigInt` literals, like `Symbol.for("a")` and `1n`
- Right-click save the resulting expressions
From there, I inspected the CDP messages being sent. Then I was able to fill in the correct fields from there, and be confident that those were correct, given that I was copying the exact behavior of Chrome itself.
Changelog:
[General][Fixed] Support properly sending BigInts and Symbols over the Chrome DevTools Protocol.
Reviewed By: neildhar, jpporto
Differential Revision: D40442228
fbshipit-source-id: 98a514edbeb35fcbd427a25475f435e22956f2db
Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This change starts adding more coverage to GitHub Actions. Existing workflows are split up to be per-platform, and stale scripts, etc are removed.
We are currently limited a bit by issues with the build itself, but this still adds a good bit of coverage that readily works, and adds places to inject more.
Another option would have been to move these to CircleCI where we have more credits, or used docker images instead of manual setup steps. etc, The Yoga build and number of changes is very light though, so we don't really need the complexity yet.
Some TODOs:
1. Fix the Apple Builds (pod lint and pod install return errors seen by the community)
2. Add working Android UTs
3. Add C++ UTs
4. Add Apple Publish
5. Add version stamping
Changelog:
[Internal][Added] - Start Adding Yoga GitHub Actions
X-link: https://github.com/facebook/yoga/pull/1165
Reviewed By: cortinico
Differential Revision: D40386426
Pulled By: NickGerleman
fbshipit-source-id: c540dd25bfec6ac8c05e461c1236ef7fe6cb8598
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## 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
-->
[iOS] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
Changelog: [Internal] Code clarity: Use enum to clarify the values parsed by JsErrorHandler
Create a enum `JSErrorHandlerKey` to define the keys for the values that goes into each stack frame.
Next up -- using this in the Bridge!
Reviewed By: sammy-SC
Differential Revision: D40326127
fbshipit-source-id: e416814fbcaa922afa92d9baf79eaa898ff979f0
Summary: changelog: Fix vertical text alignment in new architecture when line height is not 0.
Reviewed By: javache
Differential Revision: D40346225
fbshipit-source-id: f6282cb8df80e9a543e5602fddcca1a1a82377e3
Nick Gerleman
Christoph Purrer
Phillip Pan
Pieter De Baets
Adam Gleitman
David Vacca
Mitch Powell
Dmitry Rykun
Samuel Susla
Jan Kassens
Jonathan Keljo
Riccardo Cipolleschi
Donald Webster
Paige Sun
Stanley Shi
TatianaKapos
Nishan
Héctor Ramos
Lulu Wu
Michael Anthony Leon
Nick Gerleman
bang9
