Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
Add TODOs and Tasks into TODOs
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27865470
fbshipit-source-id: fcc7f86b0e6b290bf9f691a2dafea18d8addf782
Summary:
This diff adds an assert in the constructor of MapBuffer to ensure that we always access valid memory
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864310
fbshipit-source-id: bd3870b6df1dbc5181fc5d852eb0ccbc32a8a951
Summary:
EZ refactor of MapBuffer::getCount and removal of TODO
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864307
fbshipit-source-id: 14138090b3f2b45de8e0a3941abec990edb427ed
Summary:
This diff adds an assertion when trying to build a MapBuffer with invalid data
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27864309
fbshipit-source-id: 6601388e56be18ded0675f92cce009a577828c16
Summary:
Changelog: [internal]
Explicitly return undefined for `$$typeof` inside RuntimeSchedulerBinding.
React calls `$$typeof` on RuntimeScheduler. To make sure assert only triggers if unsupported value is requested, it needs to be explicitly handled
Reviewed By: mdvacca
Differential Revision: D27854472
fbshipit-source-id: 515c68d92b291cc274f5370c45e49302534e6f9c
Summary:
Changelog: [internal]
Scheduler's callback have option to add more work inside callback. This work stays on top of the priority queue and gives React ability to flush all work synchronously if need.
This diff adds use of `shouldYield_` to the workLoop. For now, it always evaluates to false. In the future when we allow access to the scheduler to native, it will allow yielding.
Relevant code in JavaScript:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L190
Reviewed By: mdvacca
Differential Revision: D27823528
fbshipit-source-id: 016101e41eb7c41c2ac5abb55f803814867b8517
Summary:
changelog: [internal]
Callback function in React is expecting a boolean parameter indicating whether the callback timed out. React team is removing it, that's why we only pass in hardcoded false.
Reviewed By: mdvacca
Differential Revision: D27794562
fbshipit-source-id: b96a7b31560524b8f38ad3bb0dbdb3b3b32ac97b
Summary:
Updates the Metro packages used in RN to v0.66.0, excluding the Metro server, which isn't a direct dependency.
Changelog:
[Internal]
Metro changelog:
https://github.com/facebook/metro/releases/tag/v0.66.0
Reviewed By: motiz88
Differential Revision: D27879399
fbshipit-source-id: e4014772d1fed2c93b32993fa2519f4e179a25a5
Summary:
Check the existence of `addListener` and `removeListeners` in the native module passed to `NativeEventEmitter` to determine if it can be used.
Changelog: [General][Changed] Show warning when native module without `addListener` or `removeListeners` is passed to `NativeEventEmitter`
Reviewed By: yungsters
Differential Revision: D27851425
fbshipit-source-id: c0ad3ba65a9239f5bf84548dab36e8dfbc51058a
Summary:
To prepare for the new architecture, introduce the following enforcement:
* Defining `RCT_NEW_ARCHITECTURE` in the build flag automatically enables violation reporting
* At runtime, call RCTEnableNewArchitectureViolationReporting() to enable/disable reporting - it takes effect with the future violations
* When violation reporting is enabled:
* RCTWarnNotAllowedForNewArchitecture(): log warning about a violation, but doesn't assert
* RCTEnforceNotAllowedForNewArchitecture(): assert when a violation happen
Also in this commit:
* Add warning when RCTRegisterModule() is called as a side effect of RCT_EXPORT_MODULE(). Many modules still need this, so we can't enforce it yet.
* Add enforcement when the bridge is initialize, because the new architecture cannot have the bridge.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D27847359
fbshipit-source-id: a8c4a8151cec3915ec707ce6b78f860af4bb0708
Summary:
The fbcode version of Skylight needs this and it is already compiling fine
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D27765879
fbshipit-source-id: 18aca2756f39326fb90397a10a67583db84076fd
Summary:
The `SPEC CHECKSUM` for `FBReactNativeSpec` in `packages/rn-tester/Podfile.lock` and in standalone apps's `ios/Podfile.lock` varies between development machines. This is caused by local paths in the output of `pod ipc spec FBReactNativeSpec.podspec`, such as `output_files` and `prepare_command`. This causes the Podfile.lock to constantly change when pod install is run on different developers' machines.
The codegen script and CocoaPods configuration have been updated to use relative paths.
Closes https://github.com/facebook/react-native/issues/31193
Changelog: [Internal] [Codegen] Avoid encoding local path in Podfile.lock
Reviewed By: fkgozali
Differential Revision: D27754337
fbshipit-source-id: 2f5607d4e1ce21489f28f394cb852c36cace6798
Summary:
Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`. This fixes https://github.com/facebook/react-native/issues/30953
## Changelog
[General] [Changed] - Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`.
Pull Request resolved: https://github.com/facebook/react-native/pull/31297
Test Plan: Tested the `TouchableWithoutFeedback` component on an Android device
Reviewed By: nadiia
Differential Revision: D27770689
Pulled By: kacieb
fbshipit-source-id: a317246021354ed288b093f8a5e6fbba43d3a04e
Summary:
The Inspector uses fbjni/JThread.h on Android platforms to get a Java
thread (with a class loader). Use a smaller scope dependency to bring
in fewer things.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D27799508
fbshipit-source-id: 3e1e00cf65596d12c9128fe636ed970238f4aba2
Summary:
Changelog: [internal]
This brings native scheduler close to React's scheduler. React's scheduler executes all tasks in the queue within a single dispatch (they use setTimeout(0) for dispatch) and makes sure to not schedule two dispatches.
Relevant JS code:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L359
Reviewed By: JoshuaGross
Differential Revision: D27793200
fbshipit-source-id: 4af13d95cfe4d33d0945f25929ccbea5f9ce5710
Summary:
Reverts D27764688 (https://github.com/facebook/react-native/commit/5a2693d78f1a886f0aa5b7f86830d3ddb54a57e9) due to a bug with "Invalid hook call." being erroneously reported. We will upgrade again after that bug is resolved.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D27813660
fbshipit-source-id: 84a12f19cf1bb7e8aebef0da3ff6f7022c391d3e
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
This is a small cleanup to move initialization out of the `constructor` as it is unnecessary, and it is currently double initializing a few values.
Changelog:
[General][Changed] Clean up the initialization of instance variables in ScrollView
Reviewed By: nadiia
Differential Revision: D27631320
fbshipit-source-id: 762277e4993a9ce86d444ff2d9e845c93e94d1a8
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:
In order to move away from the legacy system (bridge etc), we need to decouple the new architecture assumptions from it. This flag and assertion functions will help track the runtime and report violations along the way. The goal is to have 0 violation before switching over to the pure new architecture.
Note: this is not used right now.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27783246
fbshipit-source-id: 61f0d77c129bddcde7f24a803432f2d359c5bff3
David Vacca
Rick Hanlon
Pieter Vanderwerff
Paige Sun
Lulu Wu
Samuel Susla
Rubén Norte
Andrei Shikov
Gijs Weterings
Dulmandakh
Kevin Gozali
Nadiia D
Pedro Veras
Kacie Bawiec
Héctor Ramos
Carlos Cuesta
Riley Dulin
Tim Yung
Ramanpreet Nara
Joshua Gross
CodemodService FBSourceClangFormatLinterBot