Summary:
Right now we're fetching latests versions of drivers which isn't the best, we should always download the same versions.
## 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
-->
[INTERNAL] - Add versions when installing Appium drivers.
Pull Request resolved: https://github.com/facebook/react-native/pull/39275
Test Plan: CI Green - (side note: if jobs `test_e2e_ios` and `test_e2e_android` are green it doesn't mean that they passed.)
Reviewed By: cipolleschi
Differential Revision: D49248778
Pulled By: NickGerleman
fbshipit-source-id: 5b114b7dc1172993afc4b02e9d3380afa9f03c40
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/39426
When opening the react-native repo in Android Studio the first time, users is missing 3rd party native dependencies,
which gets downloaded during the first build.
Here I'm hooking the Gradle sync step to the `preBuild` task that takes care of preparing the repo so that the whole build can succeeds (i.e. downloading and unzipping native deps, running codegen, preparing hermes/hermesc, etc.).
Changelog:
[Internal] [Changed] - Make sure first Gradle Sync is downloading 3rd party deps
Reviewed By: cipolleschi
Differential Revision: D49231058
fbshipit-source-id: 11a3d436550581f8a67a582f9fd325ad39486ddc
Summary:
This mirrors the clang-format config used by fbsource to Yoga.
They are pretty similar, except for an annoying habit where Yoga's previous forced small functions in headers to be a a single line, so you would get a combination of multiline and single line functions next to each other which are hard to read. That is what motivated this change.
It also enforces header ordering (yay). I don't think we have any side-effect causing headers, so this should be safe.
Reviewed By: yungsters
Differential Revision: D49248994
fbshipit-source-id: 66998395e7c0158ff9d9fb1bee44e8401bdd8f21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39404
X-link: https://github.com/facebook/yoga/pull/1378
We thread a config through the root node, to every function, that we don't actually use (with the exception of `canUseCachedMeasurement` in the previous diff which was passing root `pointScaleFactor`).
Since the model is currently per-node config, this only creates redundancy/confusion.
I do think we might want to make some more global/layout-pass scoped configuration in the future, but likely not with this sort of drilling.
Reviewed By: yungsters
Differential Revision: D49180385
fbshipit-source-id: 91248042df7d3cea1fc316b47b8137fcb790b521
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39417
## Changelog
[Android][Breaking] - Deleting warnOnLegacyNativeModuleSystemUse
this has not fired in over a year, we should clean it up. there's an argument we want to keep this for consumers that are in the middle of upgrading, but personally i think that this needs to be built into the interop layer - currently we can only configure this in Fb specific infra.
Reviewed By: cortinico
Differential Revision: D49209540
fbshipit-source-id: 0e2bb293999ad356e564a0acf069211a7a205f21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39415
Add a simple constructor for `JSError` which does not accept a
`jsi::Runtime` and cannot call back into JSI. This guarantees that the
constructor cannot recursively invoke itself, leading to stack
overflows.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D48796703
fbshipit-source-id: 1c134e8a59ff54be64a5da901e548436d512c21d
Summary:
X-link: https://github.com/facebook/yoga/pull/1379
Pull Request resolved: https://github.com/facebook/react-native/pull/39403
Right now we have a `pointScaleFactor` per-node, but only ever read the one off the root node. In most cases where config is global, these will be the same, but it is possible for these to differ.
This... doesn't make much sense from an API perspective, and there are edge cases where we may want to allow laying out a subtree with a different DPI then the rest of the tree (though I think there might be other solutions to that).
We should rethink some of what is currently on config being allowed per-node (do we really need each node to be able to have a separate logger?), but this makes the model consistent in the meantime.
This change is breaking to any users relying on setting `pointScaleFactor` on the config of the root node, but not other nodes.
Reviewed By: yungsters
Differential Revision: D49181131
fbshipit-source-id: f1363ca242094f04b995fd50c1e56834d5003425
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/39413
`yarn android` on main is currently broken due to the CLI attempting to search for the manifest inside the src/androidTest folder.
This fixes it by specifying the exact path of the Android Manifest.
The fix to the CLI is also pending to prevent the CLI from searching inside test folders.
Fix for the CLI is here:
- https://github.com/react-native-community/cli/pull/2075
Changelog:
[Internal] [Changed] - Unblock `yarn android` on main
Reviewed By: huntie
Differential Revision: D49190626
fbshipit-source-id: 99309f17cb08a33be2a565f5faa29130862686ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39422
Those scripts were used when Buck OSS was invoking codegen. As we don't do Buck OSS anymore, we can remove them.
Changelog:
[Internal] [Changed] - Remove Codegen buck-oss scripts as they're unused
Reviewed By: huntie
Differential Revision: D49229846
fbshipit-source-id: fad0526e609bab159c56a62b85c91690e4cdbbce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39380
Changelog:
[Internal][Added] - Created a new event dispatching pipeline that immediately moves events over to the C++ queue, along with the onFrame that triggers the event beat ticking mechanism.
Reviewed By: sammy-SC
Differential Revision: D49012996
fbshipit-source-id: 0bc9067e5b019f308ec1f45ca8bd83fd195b37ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39420
changelog: [internal]
The intent of the code is to retain shared_ptr<Scheduler> but by using a reference, it didn't do that. Leading to a race condition.
bypass-github-export-checks
Reviewed By: rubennorte
Differential Revision: D49227147
fbshipit-source-id: 1a548f7174eacb95c14c89f72b51ccd263c5ab01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39357
changelog: [internal]
# Problem
## When React clones the wrong node revision
Whenever React wants to commit a new change, it first needs to clone shadow nodes. React sometimes clones from the wrong revision. This has mostly been fine, Fabric does state reconciliation to pass newest state forward. State reconciliation is needed, as we need to keep native state in the shadow tree.
However, when React clones a node that has never been through layout step, it will clone a node without any layout information and its yoga node is dirtied. Even though there might be a subsequent revision of the node with layout information already calculated. As a result, Yoga needs to traverse bigger parts of the tree, even though layout has been calculated before. It is just cached on a different revision that was used as a source.
There are two main sources (there is more but they don't help to paint the picture) when this can happen. Background Executor and State Progression. Let's start with the simpler one but less severe: Background Executor.
Background Executor moves layout from JavaScript thread. React can start cloning nodes right away, even though they might not have layout information calculated yet. This is a race condition and depending on when the node is cloned, we can see different results. In this case, React eventually clones node from the correct revision with the layout cache. It will be in a correct state in the end. This case is not as bad as far as I can tell but I included it here because it better illustrates what is going on.
State Progression is where things get worse. In this scenario, React will never clone from the correct revision and will never recover from this. Anytime React clones node with a state that needs to be progressed, it will get cloned one more time during commit but React will hold the wrong revision. Depending on where this node is located in the view hierarchy, it may lead to expensive layout calculations.
Example:
Let's use notation A/r1 as node of family A revision 1.
- React calls create node. Node A/r1 is created and React holds reference to this. It will later use it to clone it.
Node A has native state that was updated. New revision A/r2 is created. Now React and RN do not observe the same node anymore (this is sometimes necessary).
- React now clones node A to create A/r3. This revision may have the wrong yoga cache. Now this might sound like one off but let's explore what happens next.
- During commit, Fabric must do state progression to give node A/r3 state from A/r2. This requires cloning and new revision A/r4 is created. React has again a wrong node that does not have Yoga cache and can't recover from this state.
The blast radius of this varies depending on where in the tree the node is.
# Solution
Clone-less state progression. In this algorithm, state progression never clones. It checks if a ShadowNode has ever been mounted via `ShadowNode::hasBeenMounted_` to check if a node can be safely mutated without the need to clone and checks if current state the node is holding is obsolete (like the previous algorithm).
The clone-less state progression depends on the fact that any shadow node cloned from React is still unsealed and is not exposed to a multithreaded environment. This makes it safe to mutate it in place, without the need to clone.
WARNING: there is important semantic difference with the approach. With the old algorithm, you couldn't go back to a shadow node with old state. New state was always enforced when state reconciliation was enabled. The clone-less algorithm does not support that, because it can't mutate such a node in place.
Reviewed By: javache
Differential Revision: D49012353
fbshipit-source-id: 2d322f0587042c13761c83f7e916d1623159773d
Summary:
Currently, when the `_currentColorScheme` is nil the default comes from `[UITraitCollection currentTraitCollection]` which provides the trait collection of the context it was called in. Generally, this will work but in some cases the context can be different and this will return the wrong value also if the `Appearance` property is set in the plist, then initially that value is returned, regardless of if you have overridden it. Seen as the `userInterfaceStyle` of the window is overridden when the value is changed, then the default should be whatever the current style of the window is and not dependent on the calling context.
<table>
<tr><th>Before</th><th>After</th></tr>
<tr>
<td>
<video src="https://github.com/facebook/react-native/assets/30924086/3bd2d217-00f2-41d5-9229-05c31da2ecf5"/>
</td>
<td>
<video src="https://github.com/facebook/react-native/assets/30924086/6ed67e4c-dd01-40ff-84fd-0d7ffdf6534c" />
</td>
</tr>
</table>
## Changelog:
[IOS] [FIXED] - Fix the default trait collection to always return the value of the window
Pull Request resolved: https://github.com/facebook/react-native/pull/38214
Test Plan: Tested on rn-tester and verified the current behaviour is unaffected and also in our own repo to make sure it addresses the problem. Video provided above
Reviewed By: dmytrorykun
Differential Revision: D49186069
Pulled By: cipolleschi
fbshipit-source-id: f069fea8918fe17c53429564ed2a52e316ce893b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39388
This change prepare the infra to release and work properly in the dual release mode, making sure that the new architecture is turned on with some versions of react native.
It connects the diffs in the previous changes in the stack.
## Changelog:
[iOS][Changed] - Set the new arch flag based on the React Native version.
Reviewed By: dmytrorykun
Differential Revision: D49149212
fbshipit-source-id: 4d97cc2fbf64d217aec60c0d71de6ed1802ef793
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39389
The Podfile of the Template is using a function called `get_default_flags` to get the default flags.
Its behavior is duplicated in both the default value of the `use_react_native!` function and in the body of the same function, making that helper actually redundant.
In this change, we are deprecating it so we can remove it in 0.74 with no breakages.
## Changelog:
[iOS][Deprecated] - Deprecate `get_default_flags` in Ruby scripts
Reviewed By: dmytrorykun
Differential Revision: D49147290
fbshipit-source-id: 41a9f9aa4ba5d1a31d86953fe78778b45d28d9b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39390
This diff introduce an helper to read the content of the React Native package of json from ruby.
## Changelog:
[iOS][Added] - Add helper to read the package.json from the cocoapods script.
Reviewed By: dmytrorykun
Differential Revision: D49146946
fbshipit-source-id: cd25052d743a61fcfabbe197b701188ec824709e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39387
This change creates an helper function and tests to set the right value for the new arch enabled flag based on the react native version
## Changelog:
[iOS][Added] - add helper to set New Arch enabled flag based on RN version.
Reviewed By: dmytrorykun
Differential Revision: D49145515
fbshipit-source-id: c5ba0016b3be24b4529ff467cf37518624859538
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39402
X-link: https://github.com/facebook/yoga/pull/1377
To avoid keeping a per-node mapping on native Yoga nodes to Java nodes, a per-layout context was added, to be able to pass information from the start of the layout, to measure functions, log functions, etc.
The way this was done was super invasive, and added quite a few private APIs used only by the JNI functions.
This change removes the context-using functions from the JNI bindings in favor of it managing its own context. Next diff removes all the cruft.
Reviewed By: javache
Differential Revision: D49179243
fbshipit-source-id: 7e4944bead864e6b73fd2208a47c5725c18ff2b0
Summary:
X-link: https://github.com/facebook/yoga/pull/1375
Pull Request resolved: https://github.com/facebook/react-native/pull/39400
Moves `isBaselineLayout` out of `CalculateLayout` into `Baseline.h`. This function is called by flex line justification code, which I have been looking at extracting.
Reviewed By: yungsters
Differential Revision: D49177937
fbshipit-source-id: 02c13aa0b02b26cb60ef197473b90e06d53d5f8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39392
This fixes a warning that would fire for all the users on 0.73 and is not actionable in any form: https://issuetracker.google.com/issues/295235385
Changelog:
[Internal] [Changed] - Bump AGP to 8.1.1
Reviewed By: luluwu2032
Differential Revision: D49155866
fbshipit-source-id: 05201b834d00b018f8680d74fe4a40884a8c5eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39412
This fixes an issue that I got reported by users attempting to open the react-native GitHub project in Android Studio.
The error is:
```
Cannot specify include directories for target "react_codegen_AppSpecs" which is not built by this project.
```
Changelog:
[Internal] [Changed] - Fix broken Gradle Sync when opening the project with Android Studio
Reviewed By: huntie
Differential Revision: D49189331
fbshipit-source-id: 632063a7e1afc53284231be263bec352dc7057c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39355
changelog: [internal]
We want to seal node just before it is promoted.
Reviewed By: javache, NickGerleman
Differential Revision: D49054011
fbshipit-source-id: 92550c13280c68bf66d505872d86d775cf115f5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39395
Switches `EventEmitter` to use a private property.
Support for private properties was [only recently added](https://github.com/facebook/react-native/pull/39318), so this will be the first end-to-end validation of support in the `facebook/react-native` project.
Changelog:
[Internal]
Reviewed By: voideanvalue
Differential Revision: D49167908
fbshipit-source-id: 6a496ed130bfe5671663166626b1acbd80b0e9c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39394
* Constructs DevTools frontend WebSocket URLs with a client-accessible host, port and scheme derived from the initiating HTTP request (`/json` or `/open-debugger`), instead of from the static `host` and `port` parameters provided to `createDevMiddleware`. This results in more proxy-safe behaviour.
* Removes the now-unused `host` and `port` parameters from `createDevMiddleware`.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D49158227
fbshipit-source-id: ec61d98458e5d5afba4eb937b84ff65071495cc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39354
changelog: [internal]
Changes `ComponentDescriptor::adopt` to not be protected and it now accepts ShadowNode reference rather than shared_ptr.
Reviewed By: javache
Differential Revision: D49054000
fbshipit-source-id: 7aa8201277d6ef4046af45fd43360fa7af3b7d44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39406
`customCoalesceKey` is not currently used in Fabric, and we do not plan on leveraging this to do event unique'ing on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49145587
fbshipit-source-id: 6b4e76f47217e017b3a37cc0cc7081d5847eeeb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39350
While investigating excessive cloning in Fabric, I found that ScrollViewStickyHeader inadvertently changes its `ref` field, which causes the ShadowNode to be cloned.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D49058813
fbshipit-source-id: 6249f7f9553152787015df1bc02cbc223c7db30e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39399
Even after making these never report command failures, and allowing no output for thirty minutes, there are still failures here (though less) which cause lands to be aborted, especially for stacks with multiple diffs (it has prevented a recent stack of mine from landing after multiple attempts).
```
yarn run v1.22.19
$ node ./../../scripts/e2e/run-e2e-tests.js android
`isModuleDeclaration` has been deprecated, please migrate to `isImportOrExportDeclaration`
at isModuleDeclaration (/home/circleci/project/node_modules/babel/types/lib/validators/generated/index.js:3940:35)
at NodePath.<computed> [as isModuleDeclaration] (/home/circleci/project/node_modules/babel/traverse/lib/path/index.js:181:12)
/bin/bash: line 2: 14063 Hangup yarn test-e2e android 2>&1
14064 Done | tee /tmp/test_log
Too long with no output (exceeded 30m0s): context deadline exceeded
```
We are not able to detect regressions from tests while they are configured to suppress all failures, and they are still causing issues (though less), so this disables them at the job level until improvements can be made.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D49175533
fbshipit-source-id: f8b99725a57500b027874f3ef51d74c869502a22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39397
X-link: https://github.com/facebook/yoga/pull/1373
These are used to get the position origin edge from axis (same as leading edge), and dimension from axis.
Replace them with function usage, so that we can call into them from other files than `CalculateLayout.cpp`, and so that we can later use scoped enums not implicitly convertible to ints.
Reviewed By: rshest
Differential Revision: D49134566
fbshipit-source-id: cb806539ba0733a5773c594713720d465987e469
Summary:
X-link: https://github.com/facebook/yoga/pull/1374
Pull Request resolved: https://github.com/facebook/react-native/pull/39396
Yoga today has a struct `CollectFlexItemsRowValues`, and function `calculateFlexItemsRowValues()`. These names have evolved over time into something not making much sense.
The job of `calculateFlexItemsRowValues()` is a flex-wrap container into lines (i.e. line-breaking main-axis content, which may be row or column). It returns line-breaking results, but some other fields on `calculateFlexItemsRowValues()` are set much later in the process, and the struct is acting effectivelty as a holder for the line-specific values.
This change:
1. Does some renaming (mainly to FlexLine)
2. Reconciles the count `itemsOnLine` and list `relativeChildren` to list `itemsInFlow` (`relativeChildren` is a lie, as it can include elements with `YGPositionTypeStatic` and exclude relative elements which have `display: "none"`. It really just means children which are included in the layout flow for the line)
3. Makes non-changing algorithm outputs const for clarity of what is a running value, and what is a result of line-breaking values with flex basis.
4. Moves working layout values to a substructure `flexLine.layout`
5. Replaces some dishonest documentation about `endOfLineIndex`.
6. Extracts this logic out of `CalculateLayout()` to a separate file
7. Extracts `boundAxis` wholesale into a separate file, to be usable outside of `CalculateLayout.cpp`
Reviewed By: rshest
Differential Revision: D49133837
fbshipit-source-id: ec68c5a3d2f01e7c9bd8d26e28298331a3fe2475
Summary:
X-link: https://github.com/facebook/yoga/pull/1372
Pull Request resolved: https://github.com/facebook/react-native/pull/39375
D18029030 added `-fvisibility-hidden`, and a corresponding `YOGA_EXPORT` macro for defining shared library visibility. This is used inline next to function and class definitions that should be exported out of the binary.
There was already a `WIN_EXPORT` macro doing the same thing when building a DLL, defined in the headers instead of CPP files, and it seems like sometimes folks forgot to add it to new public APIs after?
This reconciles the redundant macros into a single visibility macro, that we always place with declaration instead of definition. We also rename `YOGA_EXPORT` to `YG_EXPORT` to match the naming convention of other Yoga macros.
Reviewed By: rshest
Differential Revision: D49132643
fbshipit-source-id: cafa6de0c300788a72d9a446ce07c5ac89a20a8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39374
X-link: https://github.com/facebook/yoga/pull/1371
Right now `YGConfigGetDefault` and `YGNodeGetConfig` both return mutable, freeable, configs, which is bad, since the former points to a global singleton config, and the latter usually does too. Mutating this is not thread safe, and it should never be freed.
This change makes these functions return `YGConfigConstRef` to prevent mutation, and also lets us allow `YGConfigNewWithConfig` to accept a const config. If a caller does want to mutate a config (such as to free it), it must be tracked manually.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D49132476
fbshipit-source-id: ac9ce61149e69c6c25cadb99711435b0a5b9f38a
Summary:
X-link: https://github.com/facebook/yoga/pull/1368
Pull Request resolved: https://github.com/facebook/react-native/pull/39372
These were marked as deprecated as part of the public Yoga 2.0 release, and were alredy emitting deprecation warnings. Remove them.
Reviewed By: javache
Differential Revision: D49131250
fbshipit-source-id: cc1d4e8b179697b9a11a685f4fc4e9d36e1a26a0
Summary:
X-link: https://github.com/facebook/yoga/pull/1370
Pull Request resolved: https://github.com/facebook/react-native/pull/39369
This was added in https://github.com/facebook/yoga/pull/497 specifically for tests related to memory leaks in the C# bindings to count how often YGConfigFree.
This is the wrong layer for this check, we don't have officially supported C# bindings anymore, and this API is not safe when Yoga runs on multiple threads. This removes it, similar to a global node instance count that was also previously removed.
Reviewed By: rshest
Differential Revision: D49131207
fbshipit-source-id: 58537ed635ed455ff065471bdf77061a4bf826f4
Summary:
X-link: https://github.com/facebook/yoga/pull/1366
Pull Request resolved: https://github.com/facebook/react-native/pull/39371
Yoga's public API exposes indices most often as `uint32_t`, with exception of clone callbacks which are `int32_t`. Yoga internally represents these indices as `size_t` when dealing with the child vector, and this is the true index.
This changes the API to consistently be `size_t`. This should not be breaking for most users, but will cause breaks where:
1. Users set a clone node callback (I think this should be rare. RN uses it, but only because it relies on a separate private API).
2. Callers of `YGNodeGetChildCount()` are assigning to an int with less width than `size_t` and have strong warnings enabled.
3. Using a newer Yoga binary with older source, since we are not preserving ABI compatibility (Yoga in general does not aim to be ABI stable between major versions, only ABI safe for a given set of sources).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D49130914
fbshipit-source-id: 6a004c160c4c50f68047b108508fd437156f5fac
Summary:
X-link: https://github.com/facebook/yoga/pull/1369
Pull Request resolved: https://github.com/facebook/react-native/pull/39370
This fixes const-correctness of callbacks (e.g. not letting a logger function modify nodes during layout). This helps us to continue to fix const-correctness issues inside of Yoga.
This change is breaking to the public API, since it requires a change in signature passed to Yoga.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49130714
fbshipit-source-id: 4305f8882d89f296e45b78497a51716a0dbb3b2d
Summary:
X-link: https://github.com/facebook/yoga/pull/1365
Pull Request resolved: https://github.com/facebook/react-native/pull/39368
This changes public Yoga API to in more places accept const structures where before they required mutable ones.
`resolveRef` is added as a quick way to resolve overloaded opaque refs for different types which is a bit easier to read than static_casting, and which will propagate const-ness. We also add `YGConfigConstRef`, similar to `YGNodeConstRef`. I was a bit iffy on whether we should add something to make it easier to convert to private interface, but this doesn't seem any easier to misuse than someone who looks at the internals to find the `static_cast`.
This tries to avoid more breaking changes yet, e.g. changing callbacks to require clients do not modify nodes when they are passed for logging. We also don't have const variants for returning child structures which would allow mutation of dependencies of the const object. These would need new names under the public API, since we do not have operator overloading in C.
Reviewed By: rshest
Differential Revision: D49130412
fbshipit-source-id: ee6b31b47f4622031c63dd52d8ac133d21bf29b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39335
In RTL we must have scrollview content length in order to resolve cell metrics. This means that on Paper, where layout events are bottom up, we cannot immediately calculate viewability in response to cell metric changes, as we may not yet have an accurate length of laid out list content.
This change makes us defer calculation of viewability changes in this case via `setTimeout()`, to run in a single batch after the next layout events are fired.
---
We need container dimensions to resolve the right-edge relative child directions. It is tricky to do this at a guaranteed right time with onLayout model on Paper.
When we are laying out children, the first layout on Paper looks like:
1. Child is laid out
2. Container is laid out
However, we will never see container onLayout if a child layout does not change the dimensions of the parent container. This will be the common case of subsequent child layouts, where the spacer size was accurate.
I.e. we may or may not ever see content laid out, but can only rely on having both offsets be up to date if we trigger calculation after the container layout would have happened. This is not an issue on Fabric where layout events are fired top-down, or for the most common cases of VirtualizedList, where we run calculations in idle batches that will happen after layout is set, but ends up causing problems for two scenarios I didn't originally account for:
We may recalculate cells to render immediately instead scheduling a later update if the list thinks blanking is immediate (high priority render). This means we cannot do an immediate update in response to cell layout, but we can in response to events batched after layout events are all dispatched, or in worst case delay in Paper RTL.
We do not batch/schedule viewability calculations in response to cell layout in the same wasy as we do for calculating cells to render, but do need them to trigger recalculation.
The way less hacky, but much more invasive solution, that would simplify a lot of this, would be to include parentWidth and parentHeight in onLayout events for Paper (and Fabric for consistency), so that we don't need to rely on event ordering, or sometimes not firing. I thought this would be too much at first, if we didn't have other use-cases, but am more and more tempted to tear down a lot of what we have here to do that instead, since this is not going to be able to rely on useLayoutEffect or IntersectionObserver in today's VirtualizedList because it will need to support Paper for the forseeable future..
Changelog:
[General][Fixed] - Fix invariant violation when using viewability callbacks with horizontal RTL FlatList on Paper
Reviewed By: yungsters
Differential Revision: D49072963
fbshipit-source-id: accd33e2c50935bb67700d94820f6418f130fe08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38752
changelog: [internal]
The return value is not used, let's remove it.
Reviewed By: ryancat
Differential Revision: D47916485
fbshipit-source-id: 1275b6146f8d3abe624991ed8e76abb5ac99984b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39365
The new Hermes CDP introduces new directories & headers. These need to be copied just like the other headers that Hermes API provides.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D49067283
fbshipit-source-id: 0cf11470e123bf63c645466cb066f68b50bcac4a
szymonrybczak
Alex Hunt
Nicola Corti
Nick Gerleman
Phillip Pan
Neil Dhar
Lulu Wu
Xin Chen
Jesse Watts-Russell
Samuel Susla
Alan Hughes
Riccardo Cipolleschi
Tim Yung
Moti Zilberman
Pieter De Baets
Fabrizio Cucci
zhongwuzw