Summary:
changelog: [internal]
In this diff, we delete default initialised for ShadowViewMutation to prevent accidentally creating empty ShadowViewMutation.
The other initialiser is made private and all of its uses are migrated to designated initialisers. This makes for safer API.
Reviewed By: RSNara
Differential Revision: D30774900
fbshipit-source-id: d2064bf08409850e75e13ad06558b7980a7f5d8d
Summary:
changelog: [internal]
LayoutAnimations only animates changes inside View and Paragraph nodes. This diff extends it to any node that's ViewKind.
Reviewed By: JoshuaGross
Differential Revision: D30603138
fbshipit-source-id: 63ca1e5df420149c4ba66151e97fea419fdfe631
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
Virtual views that are flattened and don't "FormsView" on-screen should not be preallocated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28811419
fbshipit-source-id: 949dcbf4cf3791355c58af785603b35fa50f3f02
Summary:
react-native-windows runs with a more strict set of warnings as errors. This fixes a bunch of warnings being hit while compiling core react-native code as part of react-native-windows. In particular warnings about mismatched signed/unsigned comparisons, lossy conversions, and variable names that conflict with names in outer scopes (yoga has a global for `leading` and `trailing` that conflicts with some local variable names)
## Changelog
[Internal] [Fixed] - Fix various C++ warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/31399
Test Plan: I've run these changes in react-native-windows. -- Shouldn't have any functionality difference.
Reviewed By: sammy-SC
Differential Revision: D28290188
Pulled By: rozele
fbshipit-source-id: 2f7cf87f58d73a3f43510ac888dbcb9ab177d134
Summary:
Add unit tests for Layout Animations.
This first batch generates a random mutation, then animates it to completion.
I found one issue with UPDATE+REMOVE+INSERT animation consistency. That shouldn't cause any crashes in production, but is a chance to improve consistency of mutations overall - and could in theory point to memory corruption, though it's somewhat unlikely.
I ran with randomized seeds, found issues, fixed them, re-ran to ensure issues were fixed, rinsed and repeated. At the end I was able to run dozens of times (with random seeds) and found nothing.
The next step is to repeatedly generate mutations that conflict with ongoing animations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28343750
fbshipit-source-id: c1c60d89a31be3ac05d57482f0af3c482b866abe
Summary:
Refactor a code block that is duplicated 2x. Logic stays the same besides renaming, and a ternary operator to decide between getting the children from "old" or "new" tree.
Tests can help us refactor knowing that the logic is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018994
fbshipit-source-id: d34a033444e67091e44ff6a747fd39846c165238
Summary:
There's a case here where we do a loop, with a map loopup, and nested map lookup inside of that. It's not particularly efficient and was done because we have multiple distinct pointers to distinct ShadowViews that are backed by the same ShadowNode. Now due to previous, recent refactoring, we can simplify this case a lot.
The code WAS correct before, just confusing and not particularly efficient. Tests can prove that this is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018996
fbshipit-source-id: a7c8148802650c88888960c9c099954e0f8bc357
Summary:
This is no longer true because of the "scope" mechanism.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018995
fbshipit-source-id: 91470234bb15f7feeb92b41613b0bbdbe42ccb27
Summary:
I am deduping a duplicated block, and adding comments to explain when we create INSERT/REMOVE mutations immediately and when we defer creation.
Theoretically the ordering of mutations will be more consistent now, which ~shouldn't matter, but is probably a decent property to have. In particular, before, in some cases
both of these orderings were possible in various scenarios:
```
INSERT X -> Y
INSERT Y -> Z
```
and
```
INSERT Y -> Z
INSERT X -> Y
```
Both of those are fine/correct/won't cause issues on any known platforms. But now, at least for the two cases touched here, only this ordering will be produced:
```
INSERT Y -> Z
INSERT X -> Y
```
meaning we build the tree from the bottom-up (the "bottom" being the root) and do out-of-order inserts less frequently.
Again, the biggest part of this diff should be readability/refactoring/de-duplicating logic, but more consistent orderings is a nice-to-have.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28017926
fbshipit-source-id: 5941588d0c8bba8b0df7d0084d5d198f4b7c2427
Summary:
Unit test case seed 1167342011 encodes a case where the differ produces a DELETE and CREATE of the same node in the same frame, which we consider an error.
It turns out this was caused by nested "unflatten" operations and this bit of deleted code specifically. We were deleting an unmatched node from a parent call's dictionary of nodes,
which prevented it from being matched in the "old" tree later on.
This is only possible now that we attach pointers to the "other" ViewNodePair when they're matched, so we can check existence of that pointer instead of inclusion in dictionaries to decide if we need to DELETE/CREATE a node and its subtree.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003330
fbshipit-source-id: 305440ef20b921883c1d6e38a4a4072e5a7f95ac
Summary:
Just adding a comment for future possible refactoring here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003338
fbshipit-source-id: ec307314d18d69f8c77c2b2afff1f3953ca55473
Summary:
These blocks either are not necessary due to other mechanisms, or are impossible to hit.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003336
fbshipit-source-id: f2321073de77c0f0173a9a0891be2a3012578b01
Summary:
Since each ShadowViewNodePair will point to any matched pair in the "other" tree during diffing, we can rely on the presence of the "other" pointer instead of
always removing nodes from `deletionCreationCandidatePairs` when they're matched.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003335
fbshipit-source-id: 0b886946eedc497091ca79c436f160b3d4bf3f1e
Summary:
There's a lot of code duplication in the differ. Reduce by factoring a duplicated code path into `updateMatchedPairSubtrees`.
This handles cases of updating trees with flattening or unflattening.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003339
fbshipit-source-id: cbbf890ba447b29d79aedea374b173de40e71334
Summary:
Simple refactor to use this struct to store lists instead of references to lists.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003337
fbshipit-source-id: a37fa23ed3c1e1b273f92bf5ad5179a0fd1d852b
Summary:
Found by running random tests and extracting a failing seed.
This error existed in master (and existed prior to recent refactors) and will be fixed by the end of this stack.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003332
fbshipit-source-id: 9c4a10d236c24337b089c44e8c1beb22358cfb05
Summary:
This code can be uncommented locally and run several times to discover new failing seeds.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003333
fbshipit-source-id: 6a3b6c08ae02bccc5c4d26067409ff6c736f8a89
Summary:
Calling `FAIL()` doesn't flush glog, but `react_native_assert(false)` does. Both will have the effect of failing the test.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003334
fbshipit-source-id: 802ad1f59e46eb048fd6ca95f5978eeaaad83f3a
Summary:
I had intended to make this change as part of the stack I landed earlier, but I had some poorly resolved merge conflicts that left this path disabled.
I verified that T76057501 no longer repros and ran unit tests.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27788467
fbshipit-source-id: 42148b887c6b3c0e815f1805e6bfb3ee58503e48
Summary:
Add mounting layer test that stress-tests differ on (un)flattening.
This fails before D27759380 and D27730952, and passes after.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27767219
fbshipit-source-id: a7e186e510f95792da6f98f80fcae5ff8ac74775
Summary:
While I think this was a very marginal bug with no known issues in the wild, incorrect layout values were sometimes being propagated to certain nodes. This would only occur during complex nested (un)flattening operations and may only impact node consistency, specifically with setting the "previous" ShadowView of mutation instructions, specifically REMOVE and DELETE. Even in rigorous testing I had trouble hitting this case and it didn't seem to impact the "next" values in CREATE, INSERT, or UPDATE.
The issue: previously `sliceChildShadowNodeViewPairsV2` assumed that the node it's operating on is a child of a non-flattened view, and the baseline origin is `{0,0}`. You can see when `sliceChildShadowNodeViewPairsRecursivelyV2` is called, a `layoutOffset` is passed in. If we ever got a list of a node that was in a flattened parent by calling `sliceChildShadowNodeViewPairsV2`, we would incorrectly assume that baseline layoutOffset for the node is `0,0`.
Now, we store the layoutOffset in the ShadowViewNodePair and can retrieve it when getting child pairs of a node.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D27759380
fbshipit-source-id: a89756190a1cb377bcc55ff31799c2afbaecdaa9
Summary:
Previously, `ShadowViewNodePair::List` owned each `ShadowViewNodePair` but whenever we put `ShadowViewNodePair` into a TinyMap, those were unowned pointer references. This worked... 99% of the time. But in some marginal cases, it would cause dangling pointers, leading to difficult-to-track-down issues. So, I'm moving both of these to be unowned pointers and keeping a `std::deque` that owns all `ShadowViewNodePair`s and is itself owned by the main differ function. See comments for more implementation details. I'm moderately concerned about memory usage regressions, but practically speaking this will contain many items when a tree is created for the first time, and then very few items after that (space complexity should be similar to `O(n)` where `n` is the number of changed nodes after the last diff).
See comments as to why I believe `std::deque` is the right choice. Long-term there might be data-structures that are even more optimal, but std::deque has the right tradeoffs compared to other built-in STL structures like std::list and std::vector, and is probably better than std::forward_list too. Long-term we may want a custom data-structure that fits our needs exactly, but std::deque comes close and is possibly optimal.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27730952
fbshipit-source-id: 2194b535439bd309803a221188da5db75242005a
Summary:
I am fixing an extremely marginal case that probably impacts nothing in production, but in theory, could - see next diff in stack for the assert that is being hit.
TL;DR in marginal, complex cases with a lot of un/flattening, we can generate the following sequence of mutations:
```
UPDATE node V1 -> V2
REMOVE node V1
```
That is incorrect, and what we actually want is:
```
UPDATE node V1 -> V2
REMOVE node V2
```
While this, again, impacts /nothing/ in prod that we know of, it would be good to get this correct so that we can enable stricter asserts (see next diff).
This will also help with debugging LayoutAnimations.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27697788
fbshipit-source-id: 47f34fe3e8107167b3df4db841d2cc14c58cb31d
Summary:
Changes in following diffs will be gated by this feature flag.
The differ in the new file is copied from the current stable implementation and will not be modified until it's deleted.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D27775698
fbshipit-source-id: 03d9518ffd2b1f25712386c56a38bd2b4d839fc2
Summary:
First, I make the breadcrumbs mechanism (landed just this week) more readable - I forgot to add separators between the breadcrumbs.
Second, there is a path that I am 99% sure we never hit. I've had comments to that effect for a ~year, but now I'm adding a falsey assert. If we don't hit it in prod after a few months I'll be more comfortable just deleting the branch entirely (while probably keeping the assert).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27697786
fbshipit-source-id: 6d74d1703b2212d069fbed510f2655ec17294458
Summary:
Move this assert so the debug logging executes first; in the case where this assert fires, we'll get a little more information (for Android, where attaching a Cxx debugger is a bit harder vs iOS).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27585132
fbshipit-source-id: e3f4cc3d78587744b9e73db685eda1fd6c36ca9d
Summary:
With all known remaining issues (outside of LayoutAnimations, potentially) resolved, enable this assert.
Note for future readers: this is the first time this particular assert has EVER been enabled widely, so if we hit this assert in dev, it's great signal for debugging BUT does not necessarily indicate any wide-spread problems in prod, or with any subsystems. This will simply help us become "more correct" over time.
It is possible, but not extremely likely, that cleaning up things that cause this assert will improve stability/crashes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27697787
fbshipit-source-id: 28fa34eba70548f5001bbd47f41dbe3c6ff3b4c1
Summary:
Allow conversion of LayoutMetrics to DebuggableString.
We also skipped a field in comparison. It probably isn't impactful in terms of production issues, but still wasn't correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27709451
fbshipit-source-id: 987fc2de0a4562a295d6cbeffdd922cbf056b811
Summary:
Changelog: [Internal]
Calls to `surfaceHandler.start()` and `setDisplayMode(DisplayMode::Visible)` in quick succession on different threads can cause a race condition between mount and commit operations.
The mountingCoordinator will try to mount an empty revision without any commits causing it to fail with:
```
TransactionTelemetry.cpp:108: function getCommitStartTime: assertion failed (commitStartTime_ != kTelemetryUndefinedTimePoint)
```
which is called from [Binding.cpp](https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp?lines=791-791&blame=1).
This change avoids this initial commit by verifying we had at least 1 revision commited before mounting it.
Reviewed By: sammy-SC
Differential Revision: D27430174
fbshipit-source-id: d208d55f02cd218a316d6fea62d0106c2bcb4be8
Summary:
Introduce a new debugging mechanism for the debugger. Outside of debug mode (you must defined `DEBUG_LOGS_BREADCRUMBS` manually to enable this feature) it will have no cost or binary size.
When the debug mode is enabled, it allows you to trace the call stack to trace what the differ is doing, making logs more useful.
Motivation: tracking down a tricky bug caught by D27585136 which originates in the differ.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27667885
fbshipit-source-id: ef75a9a1c8890f9bbe3e5b2e8a8ffcde92fb22c2
Summary:
Turns out that ShadowViews that have different LayoutMetrics will have the same hash. Fix that.
This helps for debugging LayoutAnimations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27585133
fbshipit-source-id: f0ac50619115150339089276e34fee5ddd0270bc
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
Currently we compare StubViewTrees only in contexts where equality is expected. With additional debug flags turned on, we print a verbose summary of differences between trees.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492937
fbshipit-source-id: 6851c2a4056cdbc9ae790070a3d86bb3f2b462fe
Summary:
Improve debuggability of ShadowViewTree failures by logging ShadowView hashes. This allows us to track down exactly where a change to the tree was introduced.
If necessary, if specific repros are found, logging can also be added to LayoutAnimations or other places to find out where a specific ShadowView version (identified by hash) was introduced.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27488766
fbshipit-source-id: f4866f771fc6494435fb46f09953ea69fb280a5b
Summary:
When playing around with issues in debug mode but without having a debugger attached, these logs are helpful.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407772
fbshipit-source-id: 2083901094d3bd2b0b6c6799baffcf5a60cf57ae
Summary:
This impacts Android only. It's not high-impact to check the consistency of these views and they can become "inconsistent" easily in a way that is not interesting or useful to us,
since we handle "virtual" views differently on the platform.
The need for these hacks should go away in the future if/when we account for virtual views in the differ, and stop sending redundant instructions entirely.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407779
fbshipit-source-id: 01a7ea5106ed5d94b908de03a6a710cc6275018d
Summary:
We need to do this to break a dependency cycle that would happen if we try to have `view` depend on `mounting` just to add some telemetry to `view`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26827446
fbshipit-source-id: 4c415ebf5be3a02c18c80ea8a4a77068cae0f0fe
Summary:
On Android we have the notion of "virtual views", which are defined consistently but the logic is scattered and duplicated throughout the codebase.
The logic exists to mark nodes that exist in the ShadowTree, but not the View tree. We want to CREATE, UPDATE, and DELETE them on the platform, but not INSERT or REMOVE
them. They basically exist as EventEmitter objects.
The only issue with this is (1) duplicated code, which opened the possibility for inconsistent definition (2) StubViewTree did not account for virtualized views, which caused
assert crashes in debug mode for certain LayoutAnimations on Android.
By moving the definition to ShadowViewMutation and accounting for it in StubViewTree, asserts are correct and consistent on all platforms.
This was not caught until recently, because, until recently, no asserts actually ran on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27001199
fbshipit-source-id: eb29085317037ba8a286d7813bdd57095ad4746f
Summary:
As part of stoping a Surface, we have to commit an empty shadow node tree. And to avoid a deadlock we have to do it not under a `linkMutex_`. To do so, we need to move the part that commits an empty tree from UIManager to SurfaceHandler. And this diff does exactly this.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D27010535
fbshipit-source-id: 60cc79b1c81d7340b550e78653737d2cc5bec24d
Summary:
Now cumulative time spent on text measuring is available as as part of SurfaceTelemetry.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26827445
fbshipit-source-id: 8ad3178557ea71170557fcf19b6f62f7072d6da2
Samuel Susla
Neil Dhar
Joshua Gross
Andrew Coates
CodemodService FBSourceClangFormatLinterBot
Andrei Shikov
Valentin Shergin