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/39379
We are seeing some failures in circleci that looks weird. By inspecting the tar of Hermes that should be used, they all have the right files. But then, the artifct actually used is missing something.
By looking at the log of the pod install step, it seems that the hermes-engine is not installed, thus using something stored in a previous cache.
This change should take into consideration the hermesversion also for the podfile.lock, so that we do have different Podfile.lock based on different versions of hermes.
I'm also bumping the versions of the keys to reset the caches and to keep them in sync.
## Changelog:
[Internal] - USe the hermesversion checksum in the podfile.lock keys.
Reviewed By: cipolleschi
Differential Revision: D49134827
fbshipit-source-id: c0e1dbc11ec61825f615315aa6215806b7577845
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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39366
With the recent CI optimization, we were caching the hermes-engine stored in the Pods folder in order to reuse it.
However, by doing so, we would not avtually use the hermes-engine we were building in CI nor we were using the most recent version in the E2E tests as the Podfile.lock would not have actually changed and Cocoapods would have found a proper version for the Hermes-engine.
## Changelog:
[Internal] - use the hermes engine version to invalidate cocoapods caches
Reviewed By: blakef
Differential Revision: D49125000
fbshipit-source-id: 2af81522d02a7f461fe3ab5b98a4f314013c185a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39353
changelog: [internal]
Increase the wait threshold when waiting for a task in a stub queue to reduce test flakyness.
Reviewed By: makovkastar
Differential Revision: D49093046
fbshipit-source-id: 30d150f421c226587ae9e41786d2d0f95c82dfef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39344
## Changelog:
[iOS][General] - URLs parsed by RCTConvert should be encoded respecting RFC 3986, 1738/1808
in ios 17, NSURLs are encoded respecting RFC 3986 (https://www.ietf.org/rfc/rfc3986.txt) as opposed to RFC 1738/1808 before.
following this, `NSURL`'s parsing algorithm has changed such that if they encounter a reserved character, such as `[`, the parser will percent encode all possible characters in the url, including `%`.
this causes trouble for urls that already have some encoding. for the string `%22[]`, the new parsing algorithm will return the following:
RFC 1738/1808 -> `%22%5B%5D`
RFC 3986 -> `%2522%5B%5D` (invalid encoding)
the solution here is to decode all the percentified encodings in the input string, completely stripping it of the percent encodings, and then re-encoding it. thus, the string will transform as follows:
`%22[]` -> `"[]` -> `%22%5B%5D`
we probably don't need the OS check, but including it just to be safe.
Reviewed By: yungsters
Differential Revision: D49082077
fbshipit-source-id: 21ac1e37c957db3217746f9385f9d7947261794d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39358
This adds a function polyfilling C++ 20's `std::bit_cast`, using `memcpy()` to be safe with strict aliasing rules.
This replaces the conditional code in CompactValue for type punning, an unsafe place in YGJNI where we do it unsafely, and is used in ValuePool. The polyfill can be switched to `std::bit_cast` whenever we adopt C++ 20.
Note that this doesn't actually call into `memcpy()`, as verified by Godbolt. Compilers are aware of the memcpy type punning pattern and optimize it, but it's ugly and confusing to folks who haven't seen it before.
Reviewed By: javache
Differential Revision: D49082997
fbshipit-source-id: b848775a68286bdb11b2a3a95bef8069364ac9b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39205
This diff adds affected layoutable nodes count from Yoga in the telemetry for commit revision. This is used for performance monitoring next to the timestamp information we already have.
Changelog:
[Internal] - Add affected layoutable nodes count information in Fabric commit telemetry.
Reviewed By: rshest
Differential Revision: D48671209
fbshipit-source-id: b054e5dcd465122f01500fb54cba6f6d250cd256
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39330
These tests have been moved to the Hermes repo and shouldn't be used in the React Native repo anymore.
Changelog: [General][Changed] Removed unused Hermes inspector-modern test files
Reviewed By: mattbfb
Differential Revision: D49066703
fbshipit-source-id: a1976f0830e2b54b894417db55c21d1b3f312bfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39349
This fixes these methods to ignore transforms, as per the spec:
* `offsetLeft`
* `offsetTop`
* `offsetWidth`
* `offsetHeight`
* `clientLeft`
* `clientTop`
* `clientWidth`
* `clientHeight`
`scrollWidth` and `scrollHeight` are the last methods we need to fix, as their fix is more complex than in these cases (in scroll views, the scrollable area is the overflow of all its children with transforms applied, which is an expensive computation we don't currently do, even in host platforms where this behavior doesn't work correctly).
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49069517
fbshipit-source-id: 3c4b897c904e33514cbeefa8ee317d3c2e4a1280
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39348
We removed this method from the proposal, so we don't need to keep the method around unimplemented.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49069518
fbshipit-source-id: 5b391954b125a082d7489d166b1c1cd6444cfa1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39328
This adds a new method in Fabric to get the scroll size for an element, and uses it to implement `scrollWidth` and `scrollHeight` as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607
Scroll size determine how much of the content of a node would move if the node was scrollable. If the content does not overflow the padding box of the node, then this is the same as the `client{Width,Height}` (the size of the node without its borders). If the content would overflow the node, then it would be the size of the content that would be scrollable (in other words, what would "move" when you scrolled).
If the element isn't displayed or it has display: inline, it return 0 in both cases.
These APIs provide rounded integers.
NOTE: The current implementation of `ScrollView` has several known bugs and inconsistencies across platforms (Android vs. iOS) and architectures (Paper vs. Fabric) (e.g.: content showing on top of the border on Android, `overflow: visible` only working on Android but not on iOS, etc.). The data that this API reports is the one that aligns with the Web (with a few limitations), and we'll need to fix the implementation to align with this.
NOTE: transforms are not considered correctly for the sake of this API, but also not applied correctly in any of the native platforms. On Web, the scrollable area is the overflow of all the children **with transforms applied** which isn't honored in RN. We''ll fix the data reported by this API when we also fix the user perceived behavior.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49058368
fbshipit-source-id: 39a10bf7bddec9afc54f46cc02284d601b6962f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39325
This diff extracts the logic to compute the content bounds of a shadow node (to compute its overflow insets) to a separate method. The new method is renamed as `getContentBounds` because layout metrics already have a method called `getContentFrame` that has a different meaning (the content box of the node, which excludes border and padding).
As a nice side-effect, we can now avoid executing this logic altogether if the node doesn't have overflow: visible (because we weren't assigning the result anywhere anyway).
NOTE: This method is made public because we need it to compute `scrollWidth` and `scrollHeight` in a following diff.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49020219
fbshipit-source-id: 7a65abf8523cb1dbcf0f92565fbfc228083a7d21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38671
Fix a race condition when we unmount and mount a view using FpsView too frequently. In this case, the frame loop callback didn't get a chance to unset the `mShouldStop` flag, causing the old frame loop continues to run unexpectedly.
The fix here guarantees `stop` would queue logic that removes the frame loop callback, and a later `start` would queue logic that attaches a new frame loop callback. Since both of them happens on UI thread, they are in sync.
Changelog:
[Android][Fixed] - Fix a race with FpsView on using FpsDebugFrameCallback.
Reviewed By: hoxyq
Differential Revision: D47849848
fbshipit-source-id: 8c4be40e86be128734bfa3f571fd3a1735976c7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39308
This adds a new method in Fabric to get the border size for an element, and uses it to implement the following methods as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607 :
* `clientLeft`: left border width of the element.
* `clientTop`: top border width of the element.
If the element isn't displayed or it has display: inline, it return 0 in both cases.
These APIs provide rounded integers.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D49009140
fbshipit-source-id: e667059702ca22e2b8e8721209e9c5c2553aa7ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39305
This adds a new method in Fabric to get the inner size for an element (whole size excluding borders, which would be the scrollable size of the element), and uses it to implement the following methods as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607 :
`clientWidth`: width of the element excluding the size of the left and right border.
`clientHeight`: height of the element excluding the size of the top and bottom border.
If the element isn't displayed or it has display: inline, it return `0` in both cases.
These APIs provided rounded integers.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49008698
fbshipit-source-id: 7c25b8c5ddbba7877ea398398f7a0b755e25d746
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39278
Implements tagName as the name of the component prefixed with `RN:`.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D48951824
fbshipit-source-id: 4a8387adff8ed504423d7ead7b95943bfd77ae8c
Summary:
Just increases the timeout as the E2E test runs
## Changelog:
[INTERNAL] - Add no_output_timeout: 30m to E2E jobs
Pull Request resolved: https://github.com/facebook/react-native/pull/39322
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D49056677
Pulled By: cortinico
fbshipit-source-id: c9b9af4b0fe2331a217438e303316a1f379c9e8d
Summary:
Fixes a critical networking path used commonly in graphics code, among many other use-cases. It is commonplace to store images within a single binary such as a GLB (see [KHR_binary_glTF](https://github.com/KhronosGroup/glTF/blob/main/extensions/1.0/Khronos/KHR_binary_glTF/README.md#overview)). Base64 encoded glTF can be critically slow in older browsers with an increased size, so it's not a suitable fallback for those targeting multiple platforms. Furthermore, large base64 payloads can cause crash behavior on native when passed via JSI (e.g. `expo-gl`). For textures, this can be several megabytes of high precision data, and a uri from a blob is preferred rather than writing platform-specific workarounds via the filesystem.
A user-land patch I've employed in [pmndrs/react-three-fiber](https://github.com/pmndrs/react-three-fiber), as well as [existing user-land patches](https://github.com/mrousavy/react-native-blob-jsi-helper), is to test the `Blob` constructor with an empty `ArrayBuffer`. `base64-js` is used here since it's already installed with `react-native` for binary utils elsewhere. This is declared as a dependency in the linked library since this is an implementation detail, but will be de-duplicated at install time.
```js
import { fromByteArray } from 'base64-js'
// Patch Blob for ArrayBuffer if unsupported
try {
new Blob([new ArrayBuffer(4)])
} catch (_) {
global.Blob = class extends Blob {
constructor(parts, options) {
super(
parts?.map((part) => {
if (part instanceof ArrayBuffer || ArrayBuffer.isView(part)) {
part = fromByteArray(new Uint8Array(part))
}
return part
}),
options,
)
}
}
}
```
## Changelog:
[INTERNAL] [FIXED] - Implement Blob from ArrayBuffer
Pull Request resolved: https://github.com/facebook/react-native/pull/39276
Test Plan:
Run the following at the project root to selectively test changes:
`jest packages/react-native/Libraries/Blob`
> **Note**: base64 encoding will add an additional ~33% size increase to binary data as part of this PR. This is padded to 4 bytes so a byte length of 4 will encode as 8. Native `ArrayBuffer` support would not have this behavior and remove the overhead of base64 encoding back and forth. This is a growing behavior across the networking stack, such as in `FileReader`.
Reviewed By: NickGerleman
Differential Revision: D48954160
Pulled By: dmytrorykun
fbshipit-source-id: 9d3b984aefe16bad2ee1088140b6e1160df52f55
Summary:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
Experimenting with Accessibility Inspector on iOS I've discovered that while when assigning `accessibilityRole="searchbox"` to a text input results in "Traits" reporting "Search Field" trait. However, when using ARIA-compatible `role="search"` such trait is not assigned, and text input will have an empty trait.
Afaiu this is incorrect as using `role="search"` and `accessibilityRole="searchbox"` should equivalent effect.
## 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
-->
IOS FIXED - `role="searchbox"` now assigns "Search Field" accessibility trait to a view
Pull Request resolved: https://github.com/facebook/react-native/pull/39314
Test Plan: No UI changes, it affects only accessibility.
Reviewed By: NickGerleman
Differential Revision: D49014039
Pulled By: dmytrorykun
fbshipit-source-id: 5fb194e67fbf2ac339d9a746e3ce6aaed2d32558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39291
X-link: https://github.com/facebook/yoga/pull/1359
This enables clang warnings around potentially unsafe conversions, such as those with mismatched signedness, or ones which may lead to truncation.
This should catch issues in local development which create errors for MSVC (e.g. Dash), who's default `/W3` includes warnings akin to `-Wshorten-64-to-32`.
This full set of warnings here is a tad spammy, but probably more useful than not.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D48954777
fbshipit-source-id: 1ccc07b99d09d1c2d428158149698ffd04025605
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39277
When we were reworking the Build logic in CI, we thought that the `test_ios` job and the `test_ios_rntester` jobs were the same. But, actually, they aren't.
So, now, we are seeing failures in the `test_ios` because its caches are not updated.
This changes remove the duplication of the two jobs, making sure that they use the same job, adding the possibility to run tests directly in rntester.
## Changelog:
[Internal] - Reuse test_ios_rntester to run iOS tests
Reviewed By: motiz88
Differential Revision: D48950096
fbshipit-source-id: e297d77fbd18f03873ed7a16a595e186d0e2453a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39306
This broke on Android platforms where `ReactFeatureFlags.enableViewRecycling` is enabled, as `setTransform` no longer directly mutates the transform properties, but instead goes through `setTransformProperty`
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49008194
fbshipit-source-id: 7e5543b8ce79caaaf380f20010bdde69f6e212b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39311
## Changelog:
[Internal] -
Follow up to https://github.com/facebook/react-native/pull/39284 (D48960815), which landed and broke one of the build clauses on CircleCI tests (treating unused parameters as errors, even though they are expected to be unused).
Reviewed By: hoxyq
Differential Revision: D49010472
fbshipit-source-id: 469bf3a9923b85e465d4574e69e9372c16fbc125
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39307
Make it explicit that the second arg for the State update constructor is the old State object, which we use to increment the revision.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49008431
fbshipit-source-id: 649bdd136a4a6eb25858d8bfb7c41b725e593685
