Summary:
Apple will require XCode 15 next year to ship to the app store, and it aligns with how we build and test React Native internally.
XCode 15 and 14.3 add support for a lot of [missing C++ 20 features](https://developer.apple.com/xcode/cpp/#c++20) from earlier versions as well.
Last I was aware, Riccardo was onboard with bumping min supported in 0.74 to XCode 15. This change does a slightly more conservative bump to min 14.3, and main of 15.0 (though we might want to move these before 0.74 comes out).
All of this will get migrated over to GHA soon enough as well, but... formalizing this is the only thing blocking usage of C++ 20 ranges today.
Changelog:
[ios][breaking] - Require XCode >= 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41798
Test Plan:
1. CircleCI Passes
2. Can still boot RNTester from XCode with code signing related changes.
Reviewed By: cortinico
Differential Revision: D51840617
Pulled By: NickGerleman
fbshipit-source-id: 58f8951a436eb7c892a00432a8aad0ddd0a49da1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41812
# Changelog:
[Internal]-
This makes sure that unit tests that use okhttp, do consistently use okhttp v4 for both gradle and buck based workflows when running tests.
Reviewed By: christophpurrer
Differential Revision: D51864344
fbshipit-source-id: 7fd80fd1e7e9ccdc5ec75a41c5dd03f9fc2751a0
Summary:
Changelog: [Internal]
This makes a couple objects more exact. Nothing critical, just noticed
this old branch I had created when doing some Flow upgrades in the past.
DiffTrain build for commit https://github.com/facebook/react/commit/f498aa299292d4d1e999f66d1c769440ad10d57c.
Reviewed By: hoxyq
Differential Revision: D51824015
Pulled By: kassens
fbshipit-source-id: ecadc98ffb233d6458c65c38150a29ff65a10121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41811
In this diff I'm extracting binaryCompatibilityValidator configuration into gradle.properties file. The goal is to reuse these properties from BUCK
changelog:[Internal] internal
Reviewed By: cortinico
Differential Revision: D51402033
fbshipit-source-id: 9b585dd07c5c00a39caadac47a2f0d605c5419f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41804
Those 4 tests are Ignored since a while and I haven't found a easy way to re-enable them. I believe we can safely delete them.
Changelog:
[Internal] [Changed] - Remove dead unit tests related to text/layout property settings.
Reviewed By: sammy-SC
Differential Revision: D51848089
fbshipit-source-id: 89880f5402774cb0560ac8fe4ba21e1e44c24889
Summary:
X-link: https://github.com/facebook/yoga/pull/1494
Pull Request resolved: https://github.com/facebook/react-native/pull/41788
Those tests are currently disabled due to Yoga attempting to do JNI calls.
I've added infra to bypass .so loading during tests, and we should be good to re-enable those tests by now.
Changelog:
[Internal] [Changed] - Re-enabled disabled tests ReactPropForShadowNodeSpecTest and ReactPropForShadowNodeSetterTest
Reviewed By: NickGerleman
Differential Revision: D51814491
fbshipit-source-id: adbbace19c94a0c6d8947f61221fafafd7797ac8
Summary:
X-link: https://github.com/facebook/yoga/pull/1495
Pull Request resolved: https://github.com/facebook/react-native/pull/41794
This is a copy of D51369722 to make it so that it preserves the file history
CalculateLayout.cpp is massive and approaching 3k lines. I added a few large functions dealing with layout of absolute nodes and was thinking it would be nice if that logic was just in its own file so it was more isolated and easier to reason about. So I made AbsoluteLayout.cpp and AbsoluteLayout.h to house this logic. In order for this to work I had to expose calculateLayoutInternal in CalculateLayout.h as layoutAbsoluteChild calls it. This is unideal and I would like to find a better way...
I also make LayoutUtils.h to house misc small helper methods as they are called in AbsoluteLayout.cpp and CalculateLayout.cpp
Reviewed By: NickGerleman
Differential Revision: D51824115
fbshipit-source-id: 9b27449e3c1516492c01e6167a6b2c4568a33807
Summary:
X-link: https://github.com/facebook/yoga/pull/1479
Pull Request resolved: https://github.com/facebook/react-native/pull/41682
There are two ways to get the value of a style for a specific edge right now:
1) From the inline start/end edge which is determined via the writing direction (ltr or rtl), assuming you do not have errata on
2) From the flex start/end edge which is determined via the flex direction (row, row-reverse, column, column-reverse)
There is a weird curiosity in the second case: you can define a style to be on the "start" or "end" edge when writing the stylex/css. The physical edge that this refers to is dependent on the writing direction. So `start` would be `left` in `ltr` and `right` in `rtl`, with `end` the opposite. It is **never** determined via the flex direction. Additionally, `start`/`end` takes precedence over the physical edge it corresponds to in the case both are defined.
So, all of this means that to actually get the value of a style from the flex start/end edges, we need to account for the case that one of these relative edges was defined and would overwrite any physical edge. Since this mapping is solely determined by the writing direction, we need to pass that in to all the flex start/end getters and do that logic. This is done in `flexStartRelativeEdge`/`flexEndRelativeEdge` which was added earlier but for some reason only being used on border.
Reviewed By: NickGerleman
Differential Revision: D51293315
fbshipit-source-id: 26fafff54827134e7c5b10354ff9bfdf67096f5b
Summary:
X-link: https://github.com/facebook/yoga/pull/1473
Pull Request resolved: https://github.com/facebook/react-native/pull/41491
To simplify the logic a bit I introduce a new function called `positionAbsoluteChild`. This function will, eventually, be the **sole function that matters** when determining the layout position of an absolute node. Because [absolute nodes do not participate in flex layout](https://drafts.csswg.org/css-flexbox/#abspos-items), we can determine the position of said node independently of its siblings. The only information we need are the node itself, its parent, and its containing block - which we have all of in `layoutAbsoluteChild`.
Right now, however, this is purely a BE change with no functionality different. There was a big set of if statements at the end of `layoutAbsoluteChild` that would position the node on the main and cross axis for certain cases. The old code had it so that the main and cross axis had basically the same logic but the code was repeated. This puts that logic, as is, in `positionAbsoluteChild` and calls that from `layoutAbsoluteChild`.
I will soon edit this function to actually do what it is envisioned to do (i.e. be the sole place that position is set for absolute nodes).
Reviewed By: NickGerleman
Differential Revision: D51272855
fbshipit-source-id: 68fa1f0e0f4d595faf2af1d9eaceb467382ca406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41490
X-link: https://github.com/facebook/yoga/pull/1472
This change has most of the logic needed for supporting `position: static`. We do two things here that fix a lot of the broken static test:
1) We pass in the containing node to `layoutAbsoluteChild` and use it to properly position the child in the case that insets are defined.
2) We rewrite the absolute child's position to be relative to it's parent in the event that insets are defined for that child (and thus it is positioned relative to its CB). Yoga's layout position has always be relative to parent, so I feel it is easier to just adjust the coordinates of a node to adhere to that design rather than change the consumers of yoga.
The "hard" part of this algorithm is determining how to iterate the offset from the containing block needed to do this translation described above. That is handled in `layoutAbsoluteDescendants`.
Reviewed By: NickGerleman
Differential Revision: D51224327
fbshipit-source-id: ae6dc54fe2a71bebb4090ba21a0afb0125264cbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41489
X-link: https://github.com/facebook/yoga/pull/1471
If we are going to allow the containing block to layout its absolute descendants and NOT the direct parent then we need to change step 11 which is concerned with setting the trailing position in the case we are row or column reverse. This is the very last step in the function and is positioned that way because it operates on the assumption that all children have their position set by this time. That is no longer a valid assumption if CBs layout their absolute children. In that case the CB also needs to take care of setting the position here.
Because of this problem I moved some things around. It now works like:
* If errata is set, the direct parent will set trailing position for all non absolute children in step 11
* If errata is set the CB will set trailing position of absolute descendants after they are laid out inside of layoutAbsoluteDescendants
Reviewed By: NickGerleman
Differential Revision: D51217291
fbshipit-source-id: a7eea0d3623f9041b73d609a1de2bfb0f0343a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41488
X-link: https://github.com/facebook/yoga/pull/1470
The way we plan on implementing `position: static` is by changing how we lay out absolutely positioned nodes. Instead of letting their direct parent lay them out we are going to let their containing block handle it. This is useful because by the time the containing block gets to this step it will already know its size, which is needed to ensure that absolute nodes can get the right value with percentage units. Additionally, it means that we can "translate" the position of the absolute nodes to be relative to their parent fairly easily, instead of some second pass that would not be possible with a different design.
This change just gets the core pieces of this process going. It makes it so that containing blocks will layout out absolute descendants that they contain. We also pass in the containing block size to the owner size args for `layoutAbsoluteChild`. This new path will only happen if we have the errata turned off. If there is no positioned ancestor for a given node we just assume the root is. This is not exactly how it works on the web - there is a notion of an initial containing block - but we are not implementing that as of right now.
Reviewed By: NickGerleman
Differential Revision: D51182593
fbshipit-source-id: 88b5730f7f4fec4f33ec64288618e23363091857
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41771
Changelog: [Internal]
Since we are already enforcing C++20 (and 17), we can set the namespace declaration to the C++17 style
Reviewed By: NickGerleman
Differential Revision: D51789991
fbshipit-source-id: 165d7d4e652d60ab200e2355e084010a02f470a4
Summary:
In this diff I'm integrating 'org.jetbrains.kotlinx.binary-compatibility-validator' into RN Android build gradle system.
The tool allows dumping binary API of a JVM part of a Kotlin library that is public in the sense of Kotlin visibilities and ensures that the public binary API wasn't changed in a way that makes this change binary incompatible
More context on https://github.com/Kotlin/binary-compatibility-validator#building-the-project-locally
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D51262577
fbshipit-source-id: 1894f4e55a4019e3ce1585e9df12dee69944e5ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41767
Changelog: [Internal]
Adds a simple example showing a direct recursive node in a Cxx TM.
Currently we can't auto-generate [the necessary C++ Types](https://reactnative.dev/docs/next/the-new-architecture/cxx-custom-types#struct-generator) - but we can add it later if this scenarios becomes really common.
Direct recursive nodes, can't be value types - it would require infinite memory. Hence they are nullable and managed by a smart pointer.
Reviewed By: rshest
Differential Revision: D51784136
fbshipit-source-id: f6f0710d03583bdf1e6e72ba42d8df7f8ff8d915
Summary:
Was stepping with debugger through the code & noticed few typos.
## 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
-->
[ANDROID] [FIXED] - Typos in `ReactCompoundViewGroup` comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41729
Test Plan: Typos in docs
Reviewed By: cortinico
Differential Revision: D51753447
Pulled By: arushikesarwani94
fbshipit-source-id: b373d67ca8b6c9f22d80ea1ccee98ecc5151b325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41733
I am currently implementing position: static in Yoga. I have a huge stack of changes that is ready to ship but we are waiting on the default position type to be relative before shipping. The reason being, my changes will affect a whole ton of styles where there is no position set so if we can make static no longer the default we can safely ship this new code. However, this will take a while and keeping up with this stack of diffs though merge conflicts, flakey tests, and general slowness for my IDE is getting annoying. So a solution here is to ship that stack and make it so that no one gets this functionality by changing the strict layout conformance to include the errata that is gating my changes. The end result being that the code can be shipped but will have no affect at the time being.
Right now, because that code is in a different branch and not on prod, this change will do nothing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51731778
fbshipit-source-id: f0b7fd8559adb19e1658b3ac64fcfc4c5f8ecdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41739
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: philIip
Differential Revision: D51719555
fbshipit-source-id: bad471a8a273accecb0641ccaa77223534cd45fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41738
Replacing the callsite to `context.getFabricUIManager()` in UIManagerHelper instead of `getJSIModule()`
Fixing the crash by directly making `getFabricUIManager()` of `ReactContext` independent of the assertion.
Reviewed By: philIip
Differential Revision: D51719040
fbshipit-source-id: f9118b16614724a1d6dabe59d5c4d25dd4bdbc73
Summary:
Currently React Native defines `NDEBUG` flag for all pods in Fabric only. This is useful for other libraries, like Reanimated, because they have no easy way of defining their compilation flags (at least none that I know of). Therefore defining `NDEBUG` for both architectures would be beneficial.
## Changelog:
Pick one each for the category and type tags:
[IOS] [CHANGED] - Add `NDEBUG` flag for Release builds for both architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/41715
Test Plan:
Run ruby test suite.
## Notes
For the time being I just copied
`prepare_pod_target_installation_results_mock`
and
`def prepare_installer_for_cpp_flags`
to `utils-test.rb` since I wasn't sure how to handle the installer mock.
Reviewed By: cortinico
Differential Revision: D51708382
Pulled By: cipolleschi
fbshipit-source-id: ff206f8fc151934dbae89aacd1bc69c57b4f28ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41720
We currently go via the UI thread, so we can use AsyncTask to schedule the final bit of async ReactContext destruction. This is a requirement for the AsyncTask API, which is also deprecated. We should figure out a better way to schedule and re-use threads across React Native Android, but until then, we can just create a new Thread here, which is also what we do for instance creation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51706689
fbshipit-source-id: cf17e20e91b195b956b1701e6d91d563fdba4d15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41728
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Reviewed By: philIip
Differential Revision: D51718430
fbshipit-source-id: c897ab0ee9e755e3fdb3d1e5629177818870f293
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41732
Was reading the code in this file and noticed that this comment is no longer true after D51068417 (https://github.com/facebook/yoga/pull/1460). Updated the comment to reflect the current state of things
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51730986
fbshipit-source-id: beaa5de9576d86e56def35f6e970376c7be8f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41712
I fixed the const correctness of YGConfigGetErrata a while back when fixing up other YGConfig accessors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51689323
fbshipit-source-id: 1af3deb44ec03a8a65643fa1496c534ac8f6d057
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41436
Add a JSI API for associating some native memory with a JS object. This
is intended to provide a mechanism to trigger more frequent garbage
collection when JS retains large external memory allocations, in order
to avoid memory buildup.
This diff just adds the JSI method, without any implementations.
Changelog:
[General][Added] - Added JSI method for reporting native memory to the GC.
Reviewed By: tmikov
Differential Revision: D50524912
fbshipit-source-id: c8df0e18b0415d9523e0a00f6d0ed2faa648ac68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41719
We leak ReactInstanceManager into a static singleton in `ReactCxxErrorHandler.setHandleErrorFunc`. Clean it up in `destroy()`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51706624
fbshipit-source-id: 642825ba14ff0a9710b4435f5fb6026b3a81b711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41704
`mOnViewAttachItems` was set to be be concurrent, but this would be unexpected, as all mount item operations occur solely on the main thread.
Simplify this to be just a LinkedList and annotate the methods as being UI thread only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51662154
fbshipit-source-id: 9fe5784bce8a38d1339b5e3675791414676b6f4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41711
We want the default position to be relative for a number of reasons. This should be fine for the most part but putting a killswitch around this change just in case things blow up.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51643446
fbshipit-source-id: 4f7d1e498eb663801ef6d88ba9cd9b64c781d66b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41709
We shipped these new create()/reload()/destroy() methods to the Facebook app:
- Part 1: D50802718
- Part 2: D50803283
This diff just enables them everywhere, by default.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51590843
fbshipit-source-id: 02abeea78b7b7b844552989ad58d0a2f048424ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41700
The type definition of `useMergeRefs` is incorrect, which forces all callsites to use `$FlowFixMe`. This fixes the definition and removes all the `$FlowFixMe`s caused by it.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660716
fbshipit-source-id: 4d4d3a72bdca8c409fd1dda59cc2c94113b024bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41701
I did a hotfix for this logic in D51618512. This does a small refactor to improve the code (moving more shared code to the hook and avoiding creating a closure unnecessarily in every call to it).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660288
fbshipit-source-id: 472836840b19958402bd0de3e2c09c7cec004156
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41695
When I went to update documentation, I kinda internalized how inconsistent the API is if we don't change iOS Paper.
The potential for breaks is if an iOS-specific component ignores a warning, and uses `onScroll` without `scrollEventThrottle`, then relies on `onScroll` only being called once.
It didn't seem like we hit this scenario in practice when migrating Fabric ComponentView behavior, and components will need to support it in new arch anyway, so this change takes the less conservative option of unifying the behavior everywhere.
Changelog:
[iOS][Changed] - scrollEventThrottle no longer needs to be set for continuous scroll events
Reviewed By: cipolleschi
Differential Revision: D51647202
fbshipit-source-id: e2a57f3501b9096e4033cb198bbc214d53e9913c
Nick Gerleman
Ruslan Shestopalyuk
kassens (Meta Employee)
David Vacca
Nicola Corti
Krzysztof Moch
Christoph Purrer
Joe Vilches
Ruslan Lesiutin
Gijs Weterings
Kacper Kafara
Arushi Kesarwani
Tomasz Żelawski
Pieter De Baets
Alex Taylor (alta)
Neil Dhar
Krzysztof Piaskowy
Ramanpreet Nara
Arushi Kesarwani
Rubén Norte