Summary:
X-link: https://github.com/facebook/react-native/pull/42688
Pull Request resolved: https://github.com/facebook/yoga/pull/1567
We are planning on overhauling NodeToString to output JSON instead of HTML for the purposes of better benchmarking and capturing trees in JSON format to benchmark later. This gives us a bit of a headache as we have to revise several build files to ensure this new library works, ensure that it is only included in certain debug builds, and deal with the benchmark <-> internal cross boundary that arises as the benchmark code (which is a separate binary) tries to interact with it.
On top of it all this is really not used at all.
The plan is to rip out this functionality and just put it in a separate binary that one can include if they really want to debug. That means that it cannot exist in the public API, so I am removing it here.
Private internals come next
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53137544
fbshipit-source-id: 7571d243b914cd9bf09ac2418d9a1b86d1bee64a
Summary:
X-link: https://github.com/facebook/react-native/pull/42411
Pull Request resolved: https://github.com/facebook/yoga/pull/1562
I added a small regression D52605596, where negative border would not be correctly floored. This fixes that, and starts adding tests specifically targeting the computed style API, now decoupled from the yoga node.
Reviewed By: joevilches
Differential Revision: D52930827
fbshipit-source-id: e165dade705a8de54c92d65f3664c9081137788c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1561
Back when I introduced the inline functions that would get the edge according to the writing direction I swapped some instances of `setLayoutPosition` which wrote to the flexStart edge erroneously. We should basically never read from some inline style and write to the flex edge. This changes them all to use the flex values.
Reviewed By: NickGerleman
Differential Revision: D52921401
fbshipit-source-id: 92b74d652018596134c91827806272ed7418ef6c
Summary:
X-link: https://github.com/facebook/react-native/pull/42131
Pull Request resolved: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1560
I added these when I was trying to debug the Facepile break removing the row-reverse errata caused. Yoga is doing the right thing, and the tests pass. We didn't have this specific coverage before, so add it.
Reviewed By: joevilches
Differential Revision: D52909633
fbshipit-source-id: d1e8f55bb534d76bd7dfdc46a1e1cc6f0a3ca211
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1549
X-link: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1547
X-link: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1530
Yoga has a shortcut where if a min dimension and max dimension are the same, the value acts as a definite length.
I was curious how browsers handled this.
CSS 2.1 said:
> If the containing block's width depends on this element's width, then the resulting layout is undefined
This is superceded in the CSS box sizing spec. https://www.w3.org/TR/css-sizing-3/#sizing-values
> If, in a particular axis, the containing block’s size depends on the box’s size, see the relevant layout module for special rules on how to resolve percentages. Negative values are invalid.
And later:
https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution
> Sometimes the size of a percentage-sized box’s containing block depends on the intrinsic size contribution of the box itself, creating a cyclic dependency. When calculating the intrinsic size contribution of such a box (including any calculations for a content-based automatic minimum size), a percentage value that resolves against a size in the same axis as the intrinsic size contribution (a cyclic percentage size) is resolved specially:
> If the box is non-replaced, then the entire value of any max size property or preferred size property (width/max-width/height/max-height) specified as an expression containing a percentage (such as 10% or calc(10px + 0%)) that is cyclic is treated for the purpose of calculating the box’s intrinsic size contributions only as that property’s initial value. For example, given a box with width: calc(20px + 50%), its max-content contribution is calculated as if its width were auto. (The percentage is honored as usual, however, during the actual sizing of the box itself; see below.)
> Otherwise, the percentage is resolved against the containing block’s size. (The containing block’s size is not re-resolved based on the resulting size of the box; the contents might thus overflow or underflow the containing block).
So, for the purpose of sizing the parent, the child sized using a percentage does not contribute, but we should be sizing children based on that size.
Yoga does not really work like this right now, but gets the answer right answer for half of these tests.
Reviewed By: yungsters
Differential Revision: D52251601
fbshipit-source-id: 4978b90723130283b00e87bbf49795a4d209174c
Summary:
X-link: https://github.com/facebook/react-native/pull/41776
Pull Request resolved: https://github.com/facebook/yoga/pull/1492
# Summary
In preparation to replace `CompactValue`, this fully encapsulates it as an implementation detail of `yoga::Style`.
The internal API now always operates on `Style::Length`, converted to `YGValue` at the public API boundary.
In the next step, we can plug in a new representation within `Style`, which should enable 64 bit values, and lower memory usage.
# Test Plan
1. Existing tests (inc for style, invalidation, CompactValue) pass
2. Check that constexpr `yoga::isinf()` produces same assembly under Clang as `std::isinf()`
3. Fabric Android builds
4. Yoga benchmark does style reads
# Performance
Checking whether a style is defined, then reading after, is a hot path, and we are doubling any space style lengths take in the stack (but not long-term on the node). After a naive move, on one system, the Yoga benchmark creating, laying out, and destroying a tree, ran about 8-10% slower in the "Huge nested flex" example. We are converting in many more cases instead of doing undefined check, but operating on accessed style values no longer needs to do the conversion multiple times.
I changed the `CompactValue` conversion to YGValue/StyleLength path to check for undefined as the common case (since we always convert, instead of calling `isUndefined` directly on CompactValue. That seemed to get the difference down to ~5-6% when I was playing with it then. We can optimistically make some of this up with ValuePool giving better locality, and fix this more holistically if we reduce edge and value resolution.
On another machine where I tested this, the new revision went the opposite direction, and was about 5% faster, so this isn't really a cut and dry regression, but we see different characteristics than before.
# Changelog
[Internal]
Reviewed By: rozele
Differential Revision: D51775346
fbshipit-source-id: c618af41b4882b4a227c917fcad07375806faf78
Summary:
X-link: https://github.com/facebook/react-native/pull/41964
Pull Request resolved: https://github.com/facebook/yoga/pull/1524
D52087013 (#1513) fixed some issues, including where measuring under max-content or fit-content, align-content stretch would consume the entire available cross-dimensions, instead of only sizing to definite dimension, like the spec dicates.
I missed a case, where flexbox considers a container as having a definite cross-size if it is being stretched, even if it doesn't have a definite length.
https://www.w3.org/TR/css-flexbox-1/#definite-sizes
> 3. Once the cross size of a flex line has been determined, items in auto-sized flex containers are also considered definite for the purpose of layout;
> 1. If a single-line flex container has a definite cross size, the outer cross size of any stretched flex items is the flex container’s inner cross size (clamped to the flex item’s min and max cross size) and is considered definite.
We handle `align-items: stretch` of a flex container after cross-size determination by laying out the child under stretch-fit (previously YGMeasureModeExactly) constraint. This checks that case, and sizing the line container to specified cross-dim if we are told to stretch to it.
We could probably afford to merge this a bit with later with what is currently step 9, where we end up redoing some of this same math.
Reviewed By: yungsters
Differential Revision: D52234980
fbshipit-source-id: 475773a352fd01f63a4b21e93a55519726dc0da7
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1513
X-link: https://github.com/facebook/react-native/pull/41916
Fixes https://github.com/facebook/yoga/issues/1300
Fixes https://github.com/facebook/yoga/issues/1008
This fixes a smattering of issues related to both sizing and aligment of multi-line-containers:
1. We were previously incorrectly bounding the size of each flex line to the min/max of the entire container.
2. Per-line leads were sometimes incorrectly contributing to alignment within the line
3. The cross dim size used for multi-line alignment is not correct, or correctly clamped. If the available size comes from a max constraint, that was incorrectly used instead of a definite size, or size of content. Leads were entirely skipped for min constraint.
Need to test how breaking this is, to see if it might need to go behind an errata.
See related PRs:
1. https://github.com/facebook/yoga/pull/1491
2. https://github.com/facebook/yoga/pull/1493
3. https://github.com/facebook/yoga/pull/1013
Changelog:
[General][Fixed] - Fix Yoga sizing and alignment issues with multi-line containers
Reviewed By: joevilches
Differential Revision: D52087013
fbshipit-source-id: 8d95ad17e58c1fec1cceab9756413d0b3bd4cd8f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1503
This diff makes it so that our driver will sign all of the generated files to help ensure that they are not edited by hand. Next I will add CI to actually verify the signature
Reviewed By: NickGerleman
Differential Revision: D51966201
fbshipit-source-id: f7e3f4fde1c98832212a448b2dcc8e21be0560c4
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1501
Now that we have `gentest-driver.ts` we can delete the ruby gentest. I also regened all of the tests that have a comment with the wrong file name for where it was generated.
Reviewed By: yungsters, NickGerleman
Differential Revision: D51956567
fbshipit-source-id: d389492e54711cf161dff9e649396cc40f1e5073
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1498
The only instance of ruby in this repository is `gentest.rb` used to generate test cases from html fixtures. This is quite annoying as ruby is not the most popular compared to something like Node and it does not integrate into the rest of our stack. I changed this to use Node.js instead. Instead of `watir` we now use `selenium-webdriver`. `watir` is backed by Selenium so I do not expect anything to change.
Next commits will add command line options, clean up gentest.rb and its references, and change the README
allow-large-files
Reviewed By: yungsters, NickGerleman
Differential Revision: D51874433
fbshipit-source-id: ef8588d48aa7f8b720b57df08738bbd01e9e74a3
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1488
These were disabled when they were written because they were broken. The recent changes made them pass now so lets enable them. I also added another test that is already passing
Reviewed By: NickGerleman
Differential Revision: D51404875
fbshipit-source-id: ed10004968b871c1d033640d75138f00afc15968
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1490
X-link: https://github.com/facebook/react-native/pull/41692
In the previous diffs I fixed problems with justifying absolute nodes. The same issues plague aligning so I fixed them in the same way. Added tests that were failing before but now passing
Reviewed By: NickGerleman
Differential Revision: D51404489
fbshipit-source-id: 604495d651eb67cfdcca40df9d8d3a125c5741a8
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1487
X-link: https://github.com/facebook/react-native/pull/41691
The code here was just wrong. I changed it to be the same logic as the Justify:FlexStart case, but with the flex end sides. Then I get the position for the opposite edge since we need to write to flex start side.
Reviewed By: NickGerleman
Differential Revision: D51383792
fbshipit-source-id: 372835a44edff361dbd84dd92ff9f2ec844b9f9c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1489
X-link: https://github.com/facebook/react-native/pull/41690
Centering involves centering the margin box in the content box of the parent, and then getting the distance from the flex start edge of the parent to the child
Reviewed By: NickGerleman
Differential Revision: D51383625
fbshipit-source-id: 6bbbace95689ef39c35303bea4b99505952df457
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1483
This test is for ensuring caching does not break layout when a CB changes. No changes were needed to get this passing it just works this way with the implementation we chose earlier.
Reviewed By: NickGerleman
Differential Revision: D51333812
fbshipit-source-id: b3b603fc641d470cb61e63c44c71f7544f3c7727
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1485
X-link: https://github.com/facebook/react-native/pull/41686
The size of the containing block is the size of the padding box of the containing node for absolute nodes. We were looking at `containingNode->getLayout().measuredDimension(Dimension::Width)` which is the border box. So we need to subtract the border from this.
Added a test that was failing before this change as well
Reviewed By: NickGerleman
Differential Revision: D51330526
fbshipit-source-id: adc448dfb71b54f1bbed0d9d61c5553bda4b106c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1482
X-link: https://github.com/facebook/react-native/pull/41685
This is the final step (that I know of) to get the core features of static working. Here we turn on all of the tests and pass down the correct owner size for the call to `calculateLayoutInternal` that is in `layoutAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51293606
fbshipit-source-id: 972259e7ebecb19b55aef2ef866bd7cb57aaf0ca
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1496
Gentest code has a problem where we try to apply a border in our test when the web browser is not actually adding one. This happens when we do something like `border-top: 10px`. This will actually set the style of the border to `initial` which is just `none`, so nothing renders. This is causing at least 1 test to pass when it actually fails.
I changed it so we ignore setting this value if the style is one of these values. I then re-ran the gentest code and excluded the now failing test (which gets fixed in my static stack).
Reviewed By: NickGerleman
Differential Revision: D51831754
fbshipit-source-id: a325e4a42b2d7cd6f19efc6cd5a2445574467fb7
Summary:
X-link: https://github.com/facebook/react-native/pull/41480
Pull Request resolved: https://github.com/facebook/yoga/pull/1469
The previous version of static didn't do anything inside of Yoga. Now that we're making it do something, this changes the default back to relative so that users with no errata set don't see their deafult styles changing.
Reviewed By: joevilches
Differential Revision: D51182955
fbshipit-source-id: c0ea357694e1367fb6786f1907dfff784b19a4bc
Summary:
X-link: https://github.com/facebook/react-native/pull/41394
Pull Request resolved: https://github.com/facebook/yoga/pull/1463
Now that are enums are unsigned, and we don't have BitfieldRef, we can convert the last remaining user of NumericBitfield to a plain old bitfield, for better readability (e.g. the default values), debugability, and less complexity. We also break a cycle which lets us properly group public vs private members.
Reviewed By: joevilches
Differential Revision: D51159415
fbshipit-source-id: 7842a8330eed6061b863de3f175c761dcf4aa2be
Summary:
X-link: https://github.com/facebook/react-native/pull/41392
Pull Request resolved: https://github.com/facebook/yoga/pull/1458
We're moving `CompactValue` to be an internal detail of `yoga::Style`, where users outside of the style will be dealing with a resolved/non-compact representation.
This change renames usages of `CompactValue` to `Style::Length`, which will be Yoga's representation for CSS input lengths. Right now one is just a type alias of the other, but this will let us change the internals of CompactValue with the rest of the world looking the same.
A few factory functions are added to `yoga::value` for creating CSS values. There are some shenanigans around how we want to represent CSS pixels (one YGUnitPoint), when we also end up adding CSS points (slightly larger than one YGUnitPoint). For now, I reused `point` until making other changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D51000389
fbshipit-source-id: 00f55e72bfb8aa291b53308f8a62ac8797be490f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1476
Up the stack, Style uses just plain getters and setters. These tests aren't particularly useful enough to update.
Previously landed as part of D50998164
Reviewed By: joevilches
Differential Revision: D51481328
fbshipit-source-id: b0413270fd5951c7c8d783269b08cca9f939ce25
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1475
X-link: https://github.com/facebook/react-native/pull/41568
Removes cases where we rely on comparing composite of Yoga edges, since we are removing that internal API (public API is already one at a time). Extracted from D50998164, with more sound facility for looping through edges.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51478403
fbshipit-source-id: 162170b91345ff86db44a49a04a2345f0fbd0911
Summary:
X-link: https://github.com/facebook/react-native/pull/41347
Pull Request resolved: https://github.com/facebook/yoga/pull/1453
This follows the previous patterns used for `Gutters` and `Dimension`, where we hide CompactValue array implementation from `yoga::Style` callers.
This allows a single read of a style to only need access to the resolved values of a single edge, vs all edges. This is cheap now because the interface is the representation, but gets expensive if `StyleValuePool` is the actual implementation.
This prevents us from needing to resolve nine dimensions, in order to read a single value like `marginLeft`. Doing this, in the new style, also lets us remove `IdxRef` from the API.
We unroll the structure dependent parts in the props parsing code, for something more verbose, but also a bit clearer.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50998164
fbshipit-source-id: 248396f9587e29d62cde05ae7512d8194f60c809
Summary:
X-link: https://github.com/facebook/react-native/pull/41346
Pull Request resolved: https://github.com/facebook/yoga/pull/1452
This removes the last remnant from `Yoga-interna.h`, `YGNodeDellocate()`. The API is renamed to `YGNodeFinalize` to give it the explicit purpose of freeing the node from a garbage collector, and made public with that documented contract.
With that, every top-level header is now a public API, and Yoga's JNI bindings do not need to rely on private headers anymore.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51014340
fbshipit-source-id: 553f04b62c78b76f9102cd6197146650955aeec5
Summary:
X-link: https://github.com/facebook/react-native/pull/41293
Pull Request resolved: https://github.com/facebook/yoga/pull/1446
NickGerleman pointed out that my recent changes to fix the slew of row-reverse problems in Yoga actually ended up regressing some parts. Specifically, absolute children of row-reverse containers would have their insets set to the wrong side. So if you set left: 10 it would apply it to the right.
Turns out, in `layoutAbsoluteChild` there were cases where we were applying inlineStart/End values to the flexStart/End edge, which can never be right. So I changed the values to also be flexStart/End as the fix here.
Reviewed By: NickGerleman
Differential Revision: D50945475
fbshipit-source-id: 290de06dcc04e8e644a3a32c127af12fdabb2f75
Summary:
`child.offsetLeft/Top` calculates the offset from child to its nearest positioned ancestor, not its direct parent. These are often the same and have not mattered in the past since we have not supported position static. Since are are in the process of supporting that, we would like our tests to be usable so this adjusts the gentest methodology to only speak the same language as Yoga - that is left/top are always relative to direct parents.
It works by using `getBoundingClientRect().left/top` instead. Then we pass that down to children and subtract it from the childs `getBoundingClientRect()` to get the position relative to the parent. Note we have to round the final result as `child.offsetLeft/Top` is rounded.
Reviewed By: NickGerleman
Differential Revision: D51053629
fbshipit-source-id: 8809588d12953565228ae50fdf38197213c46182
Summary:
I was playing around with absolute children and padding and noticed an issue so adding tests to track.
Made a github issue: https://github.com/facebook/yoga/issues/1436
Reviewed By: yungsters
Differential Revision: D50670457
fbshipit-source-id: 4672d1e8b831a0a42509d95e91178944fc0f5c06
Summary:
Doing some test-driven-development to support this feature, so I will start by adding a ton of tests to ensure the nuance of position: static is captured in Yoga. Specifically I have a slew of tests to capture:
* Insets have no effect on static elements
* Insets are relative to the nearest non-static ancestor
* Percentage values for insets, padding, and margin of absolute children respect the correct dimension of the nearest non-static ancestor
* Also added similar ones for static and relative children which should just respect their ancestor (static only because it is a flexbox by default)
* This rule does NOT apply to border
* The containing block for absolute children is the padding box of their nearest non-static ancestor
* The containing block for static children is the content box of their parent (because all elements are flex containers in yoga, at least right now)
Reviewed By: NickGerleman
Differential Revision: D50475939
fbshipit-source-id: 7988ffc9bea3317875128dd1908d787b9b714a45
Summary:
I am about to embark on supporting `position: static` in Yoga. The enum exists already (and is the default position type, lol) but does not actually do anything and just behaves like `position: relative`.
My approach here is to write a bunch of tests to test for the various behaviors of static positions and then develop on Yoga afterwards to get those tests passing. To do this, we need to make a few changes to the gentest files as there is not support for adding `position: static` at the moment:
* Make it so that the gentest code can physically write `YGPositionTypeStatic` if it encounters `position: static` in the style
* Make it so that gentest.js knows that Yoga's default is actually static. This way the code generated in the tests will actually label nodes for non default values
* Explicitly label the position type even when it is not declared in the style prop (with the exception of the default)
* Regenerate all the tests
Additionally I added the first, basic test: making sure insets do nothing on a statically positioned element.
Reviewed By: NickGerleman
Differential Revision: D50437855
fbshipit-source-id: 0e8bbf1c224d477ea4592b7563d0b70d2ffa79c8
Summary: Now that the tests are passing let's not skip it anymore. Also adding errata tests to make sure most prod builds are still protected.
Reviewed By: NickGerleman
Differential Revision: D50390993
fbshipit-source-id: cb91a7a377e919eaca24fb25e3d73d3c92eb8931
Summary:
These tests were a bit weird for testing something with position. The gentest setup makes it so that the fixtures are wrapped in a absolutely positioned container with height and width bot 0. However, the generated yoga tests do NOT do this and instead have the root node as the fixture itself with no wrapping container.
This causes a problem when testing left/right/top/bottom position insets. Because left/right/top/bottom will position the element relative to its containing block when position is absolute, we will get different values on yoga and chrome even if the implementation is correct: https://developer.mozilla.org/en-US/docs/Web/CSS/right#description
To fix this, we just wrap the fixture in a set size div that is also absolutely positioned.
The file was also formatted.
Reviewed By: NickGerleman
Differential Revision: D50389229
fbshipit-source-id: ecd23939b973225cfb0611dc87f30c262952c5fc
Summary:
X-link: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
Pull Request resolved: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary: this is fixed now so we can turn it on
Reviewed By: NickGerleman
Differential Revision: D50348206
fbshipit-source-id: 61c2a72164c6f0ee91b1b5b576d3f129e8cfbe40
Summary: after looking into the issue described in https://github.com/facebook/yoga/issues/1208 it seems to apply to position too, so adding tests to confirm
Reviewed By: NickGerleman
Differential Revision: D50154056
fbshipit-source-id: 64dd04ce3ad765526a547fe60b699b664f251c06
Summary: after looking into the issue described in https://github.com/facebook/yoga/issues/1208 it seems to apply to border too, so adding tests to confirm
Reviewed By: NickGerleman
Differential Revision: D50153472
fbshipit-source-id: a50f3e040153086b6a573924b513919dbb94f3c0
Summary: after looking into the issue described in https://github.com/facebook/yoga/issues/1208 it seems to apply to padding too, so adding tests to confirm
Reviewed By: NickGerleman
Differential Revision: D50153085
fbshipit-source-id: bad0ef50389a71a45ec3a58d87c1dea0c2b26024
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1411
X-link: https://github.com/facebook/react-native/pull/39796
Pull Request resolved: https://github.com/facebook/yoga/pull/1414
GCC flags that `isUndefined()` is not declared `constexpr` but that `unwrapOrDefault()` is. `std::isnan` is not constexpr until C++ 23 (because we cannot have nice things), so I made `yoga::isUndefined()` constexpr, using the same code `std::isnan()` boils down to. I then made `FloatOptional` depend on `Comparison.h` (instead of the other way around), so we can use it.
Note that the use of the `std::floating_point` concept here requires the libc++ bump in the previous diff in the stack.
Reviewed By: yungsters
Differential Revision: D49896837
fbshipit-source-id: 61e2bbbfedecffd007a12d42d998e43d3cf5119c
