Summary:
This fixes multiple compile errors when building RNTester with Hermes enabled:
- `Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')`
- `'event2/event-config.h' file not found`
- tons of missing files (all added to RCT-Folly/Futures)
Changelog: [iOS] Fix Hermes build on folly version 2021.04.26.00
allow-large-files
Reviewed By: RSNara
Differential Revision: D28128087
fbshipit-source-id: ee7cb6fda72d00d22f6182d958aa8ba55939f158
Summary:
Implement the API for querying the properties of an object found in a
heap snapshot.
Now when you are debugging and take a heap snapshot, you can hover
over an object and inspect it!
Only works for subclasses of JSObject. Doesn't work for stuff like HiddenClass,
PropertyAccessor, native objects like WeakValueMap, etc. Those internal objects
display "Preview is not available" which matches what Chrome prints for its own
internal stuff.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D27834672
fbshipit-source-id: 607a8984b5a48b76c5ae57f9bd5bf53168f3ec3f
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
Changelog: [internal]
state infra uses rvalue references until this point. I assume the original author intended to rvalue reference even here.
This way, we avoid unnecessary copy.
Reviewed By: JoshuaGross
Differential Revision: D28057570
fbshipit-source-id: 19af480234d44acffcdbb22606607279e25c8aed
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:
This was missing, causing the test to fail.
Changelog:
[Internal]
Reviewed By: mhorowitz
Differential Revision: D28009429
fbshipit-source-id: 51d4366b4feb6a2300c5bd05007dd9455bdcd77b
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:
Changelog: [internal]
Current implementation of `AsynchronousEventBeat` dispatches lambdas through `RuntimeExecutor` regardless if it has done so previously.
So if `AsynchronousEventBeat::induce` is called 30 times, it will dispatch 30 lambdas.
In `AsynchronousEventBeatV2`, we make sure only single lambda is dispatched to `RuntimeExecutor` at a time.
Reviewed By: mdvacca
Differential Revision: D27940300
fbshipit-source-id: 2bad25c86315c1712b4a1da8c1d4702734cec70f
Summary:
Changelog: [internal]
EventPriority is backed by int, passing it by reference doesn't provide any performance benefits. Quite contrary, it can make it slower because of indirectness (in our case it is probably negligible).
Reviewed By: mdvacca
Differential Revision: D27938600
fbshipit-source-id: 37d1312627dd5a8f9012dfb35d21afe716a16ad7
Summary:
## Motivation
With the bridge, every call into JS flushes the queue of NativeModule calls. Fabric bypasses this mechanism, because it uses a RuntimeExecutor that schedules work directly on the JavaScript thread. This diff makes Fabric's RuntimeExecutor also flush the queue of NativeModule calls.
This likely won't fix anything in Fabric, because we don't execute any async NativeModule calls on Fb4a. However, this is necessary for the drainMicrotask work we're doing in D27729702 (https://github.com/facebook/react-native/commit/73108477589a18cecb303ef556fa3da02f8ca1b8), because (1) we need to drain the Hermes microtask queue on every call from C++ -> JavaScript (2) we drain the microtask queue [inside JSIExecutor::flush()](https://github.com/facebook/react-native/blob/de477a0df6da770e579892d4875a8995c430ebdf/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp#L427,L445).
Changelog: [Android][Fixed] - Flush JSIExecutor in Fabric's RuntimeExecutor
Reviewed By: JoshuaGross
Differential Revision: D27975839
fbshipit-source-id: 27f031fb36593253da116a033e30998475eb1473
Summary:
RuntimeExecutor is currently declared inside NativeToJsBridge. It doesn't need to be: Instance.cpp can use NativeToJsBridge::runOnExecutorQueue to schedule work on the JS Thread. So, this diff moves RuntimeExecutor out of NativeToJsBridge into Instance.cpp. Now, both the JS CallInvoker and the RuntimeExecutor are declared in the same file.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27975840
fbshipit-source-id: aa06f479fa24bb7a15bfd21712df5414a183266c
Summary:
Fix a bug in the constructor of `LineMeasurement` where it did not initialise `xHeight` correctly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27972942
fbshipit-source-id: a56d55fdfe286bd11a6a81a3d024504f070bdb19
Summary:
## Rationale
With the bridge, the invalidate method of every TurboModule gets called on the TurboModule's method queue. This ensures that we can safely clean up resources accessed in the TurboModule's async methods. In bridgeless mode, we don't invalidate each module on its method queue. After this diff, we will clean up every TurboModule on its own method queue.
## Changes
- Make RCTInstance dealloc itself on the JavaScript thread.
- Terminate the JavaScript thread on the JavaScript thread. This ensures that no work executes on the JavaScript thread after we clean up RCTInstance.
- Make [RCTTurboModuleManager invalidate] execute right before RCTInstance terminates the JavaScript thread.
- **Fix:** Make [RCTTurboModuleManger invalidate] synchronously invalidate modules on their own method queues.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D27933587
fbshipit-source-id: 7630e7fc074df2f5a3293192431105c747b8588f
Summary:
Changelog: [Internal]
This diff introduce a helper `performMicrotaskCheckpoint` to
repetitively invoke `jsi::Runtime::drainMicrotasks` to exhaust
the microtasks queue provided by JS VMs. Please refer to `jsi.h`
for more details about the behavior of the API.
Conceptually, the checkpoint needs to be performed whenever the
JS stack is considered empty. In practice, we can just make a
call whenever RN is returned from C++->JS calls.
In the current RN, this happened in JSIExecutor:
- `::callFunction` => `callFunctionReturnFlushedQueue_-> call`
- `::invokeCallback` => `invokeCallbackAndReturnFlushedQueue_-> call`
- `::flush` => `flushedQueue_->call`
Each of them invoke a bound method on the JS bridge object. Note
that `setImmediate` callbacks are executed before they returned.
This means immmediates are invoked before engine microtasks. This
is okay because the priority between `setImmediate` and engine
"microtask" are not defined. (`setImmediate` is non-standard and RN
already treat `setImmediate` in a similar priority as microtask
for the existing Promise polyfill.)
Reviewed By: RSNara
Differential Revision: D27729702
fbshipit-source-id: b64b3705d2ff5100075d860c89f03a847369b7ac
Summary:
Changelog:
[Internal][Added] - Introduce drainMicrotasks to JSI
This diff proposed a new JSI API `drainMicrotasks` to define
how hosts may integrate with the JSVMs' internal microtask
queue (a.k.a. job queue) and hence their native Promise.
The name `drainMicrotasks` is slightly preferred over `drainJobs`
to favor *host-friendliness* over *engine-friendliness*.
This diff auto implement the new API in JSC and Hermes as stubs
to make sure things compiled.
Please refer to the doc-comments in the `jsi.h` for a detailed
documentation on the semantics and the design of this API.
### Notes on the existing APIs from JSVMs
The presence of such queue and APIs to operate on them are
ubiquitous:
- Hermes: `Runtime::drainJobs`
- V8: `MicrotaskQueue::PerformCheckpoint`
- JSC: `VM::drainMicrotasks`
- QuickJS: `JS_ExecutePendingJob`
The only exception is ChakraCore, which requires hosts to provide
the queue and set up the `JsSetPromiseContinuationCallback`,
but a JSI implementation can provide that queue trivially.
### Extra note on ECMA-262
ECMA-262 changed the spec at Mar 2020 from "asking an ECMAScript
implementation to maintain a Job Queue" to "Ask the embedder to
define its event loop, including the job queue" so technically:
- the internal approach is closer to the old spec.
- the ChakraCore approach is closer to the current spec.
Reviewed By: mhorowitz
Differential Revision: D27727920
fbshipit-source-id: b839b959facbc009f7d14b781e9287c46ea64373
Summary:
Changelog: [internal]
`ssri` usages came from `webpack` so we ran
`yarn upgrade "webpack"`.
Reviewed By: dulinriley
Differential Revision: D27922406
fbshipit-source-id: cddca21a8035d3bd303f8cea82afe2264b35eed1
Summary:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
There was a subtle bug in MapBufferBuilder::ensureDynamicDataSpace where in some situations allowed MapBufferBuilder to use unowned memory.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904642
fbshipit-source-id: de447633349094b0e8c5cb5e377dd31f5bfd1471
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Dynamicdata can contain long datastructures, increasing type of MapBufferBuilder.dynamicDataSize to int
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904647
fbshipit-source-id: ccbccf9328a6aa301aa3f9bf5c1b3c20f56e2a19
Summary:
found a bug in MapBuffer.getString() method, this diff is fixing it
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904644
fbshipit-source-id: 746812235539ff75c5ce53c6f872ede9779fa1fa
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
Peter Argany
Riley Dulin
Samuel Susla
Joshua Gross
Tim Yung
Ramanpreet Nara
Neil Dhar
Xuan Huang
David Vacca