Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1556
X-link: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
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/1542
`YGNodeSetAlwaysFormContainingBlock` -> `YGNodeSetAlwaysFormsContainingBlock`
Started getting tasks telling me github CI was broken. Turns out I was just mispelling this.
Its not a big deal but we really should ensure that stuff will not land if it break github CI...not in our wheelhouse but it seems quite silly that this happens.
Also, a lot of the random files do not have auto complete or code checking which is why I didn't notice this to begin with.
Reviewed By: NickGerleman
Differential Revision: D52632257
fbshipit-source-id: 367ae5766ef9baecf55f7c227ff9fc8dece43af6
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/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/1500
Inspired by the frequent usage of Expo snacks to run RN, to repro Yoga issues, this replaces the Playground port with a new ground up Playground UI. This UI right now is pretty simple, with a JSX editor which creates a Yoga tree, which is then rendered using the WebAssembly variant of Yoga.
There are a lot of ways we can continue to improve this, but this merges the foundation. Subjectively, I find this more useful as a tool to play with Yoga behavior than the GUI.
This also replaces some of the bits of the homepage, and adds a playground entrypoint (though it's pretty identical to the one I've been testing on the home page).
Reviewed By: yungsters
Differential Revision: D51963201
fbshipit-source-id: 1265cb1784151b685686e189d47ecd42cbacdf8f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1506
In order to build the website, you must build a Yoga binary. This usually requires installing native toolchains.
We have warning messages for these right now, but an even better solution is to just manage the dependencies ourselves. This does that, bringing in specific CMake and Ninja binaries from NPM, and caching a local copy of Emscripten during the build.
A downside is that the CMake packages are chunky, so we add 130MB to node_modules (for a repo total around 350MB). This also delays acquiring Emscripten (which is even chunkier) in CI builds until it is needed, and I added some caching for it as well.
The upside of JS users being able to run and test (inc the website) without installing and managing their own versions of toolchains is a real time-saver though, and is probably worth it.
allow-large-files
Reviewed By: yungsters
Differential Revision: D52013026
fbshipit-source-id: 3d307f751463a21c5e5d5b98b8e9e63db9d3d52e
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/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/1481
X-link: https://github.com/facebook/react-native/pull/41684
Absolute nodes can be laid out by themselves and do not have to care about what is happening to their siblings. Because of this we can make `positionAbsoluteChild` the sole place where we handle this logic. Right now that is scattered around algorithm with many `if (child is absolute)` cases everywhere. This makes implementing position static a lot harder since we are relying on the CB to do all this work, not the parent.
With this change the only time we set position for an absolute node and it matter (i.e. not overwritten) is in `positionAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51290723
fbshipit-source-id: 405d81b1d28826cbb0323dc117c406a44d381dff
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/41423
Pull Request resolved: https://github.com/facebook/yoga/pull/1466
Right now Yoga's main branch says it's 2.0.0, and RN's dirsync says its 1.14.0, but the code is really closer to what will be Yoga 3.0.0.
This changes trunk builds to "0.0.0" for clarity, which will be assigned a real version number the first time publishing a new Yoga branch.
This is separately a good practice to prevent the chance of accidental publishes causing damage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51236778
fbshipit-source-id: 06cac89bcca1c707ce5c00f9c346f627eef6b4bc
Summary:
X-link: https://github.com/facebook/react-native/pull/41420
Pull Request resolved: https://github.com/facebook/yoga/pull/1465https://yogalayout.com now redirects to https://yogalayout.dev
This replaces references to "yogalayout.com" with "yogalayout.dev", the same website, with a new domain. This includes:
1. Code comments
2. Yoga website config (publish action CNAME, Docusaurus config)
3. Documentation URLs in Yoga packages
Changelog:
[General][Fixed] - "yogalayout.com" to "yogalayout.dev"
Reviewed By: christophpurrer
Differential Revision: D51229587
fbshipit-source-id: b1c336a52aab5e02565071b61430d5435381dc0a
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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1447
Just ran
```
ruby xplat/yoga/gentest/gentest.rb
```
It seems that D50453324 changed a bunch of the import directories in these test files but for some reason it did not get picked up for this test. As a result we are seeing failing github checks like https://github.com/facebook/yoga/actions/runs/6738747977/job/18318958442. Should be good now.
Reviewed By: yungsters
Differential Revision: D50951161
fbshipit-source-id: a2472022782f64f840a64ed991f5f35c3ef556dc
Summary:
Fixes https://github.com/facebook/yoga/issues/1417
This dramatically simplifies the matrix of Node vs web, ASM vs WASM, sync vs async compilation, or CommonJS vs ES Modules. We have one variant, using wasm, with ESModule top-level await to do async compilation. Web/node share the same binary, and we base64 encode the WASM into a wrapper JS file for compatibility with Node and bundlers.
This has some downsides, like requiring an environment with top level await, but also has upsides, like a consistent, sync looking API compatible with older Yoga, and mitigating TypeScript issues with package exports and typings resolution.
As part of this work I also removed `ts-node` from the toolchain (at the cost of a couple of config files needing to be vanilla JS).
Pull Request resolved: https://github.com/facebook/yoga/pull/1433
Test Plan:
1. `yarn test`
2. `yarn lint`
3. `yarn tsc`
4. `yarn benchmark`
5. `yarn build` website-next
6. `yarn lint` website-next
7. Locally test website-next
8. Examine package artifact created by GitHub
9. All Automation passes
Reviewed By: yungsters
Differential Revision: D50453324
Pulled By: NickGerleman
fbshipit-source-id: fe1192acc69e57fa69a1ff056dd7b5844d2198d5
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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1434
X-link: https://github.com/facebook/react-native/pull/41130
I will use this errata to gate my changes that actually make position: static behave like the web. We have future plans to make position: relative the default again but users could still have declared certain nodes as position: static, so I think this is needed regardless.
Reviewed By: NickGerleman
Differential Revision: D50506915
fbshipit-source-id: b0d9e6883167de6ff002352c9288053324464cb9
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:
Yoga has a known bug where marginStart and marginEnd will swap with row-reverse flex direction. This is not the intended behavior. On Paper this is also an issue with marginLeft and marginRight (at least we think Paper is the culprit, not exactly clear yet).
margin-start (and end) is not actually valid css. The gentest.rb script will just turn this into margin-left, but the cpp generated will properly test marginStart. This seems a bit weird to be since marginStart != marginLeft AFAIK. Things like RTL and LTR modes might make this test not exactly right. But given how many other tests depend on this quirk I think it is fine to add as is - the end result is the same after all. If not, a followup would be to add support for mapping margin-inline-start (valid css) to marginStart.
Anyway, this diff is to add test coverage for this scenario. Next stop is to actually try to fix this problem, which may be a bit harder :P
See https://github.com/facebook/yoga/issues/1208 for more info.
Reviewed By: NickGerleman
Differential Revision: D49744271
fbshipit-source-id: 75b8dd0cc5c53b2f338476fb70b60006aaa89054
Summary:
If the first element of a line is not contributing (e.g. position absolute), an additional gap will be added to the line, because the first gap element of the line is never identified (wrong start index).
Fix: raise the index of the first line element until we find an element that is contributing to the line.
Pull Request resolved: https://github.com/facebook/yoga/pull/1408
Reviewed By: yungsters
Differential Revision: D49722065
Pulled By: NickGerleman
fbshipit-source-id: 1068cb0b11ae4b04ec8d063e70540cce06181d5a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1382
X-link: https://github.com/facebook/react-native/pull/39437
Have been running into places where C++ 20 makes life easier for use like `std::bit_cast` (that one is easy to polyfill), in-class member initializer support for bitfields, designated initializers, defaulted comparison operator, concepts instead of SFINAE, and probably more.
Our other infra is in the process of making this jump, or already has. This tests it out everywhere, across the various reference builds, to see if we have any issues.
This is a bit more aggressive than I had previously communicated, but n - 1 is going to be a better long term place than n - 2.
If we wanted to use `std::bit_cast` we would need one of:
1. GCC 11+ (~2.5 years old)
1. Clang 14 (~2.5 years old)
1. VS 16.11 (~2 years old)
For mobile this means:
1. NDK 26 (still in Beta 😭)
1. XCode 14.3.0 (~6 months old)
https://en.cppreference.com/w/cpp/compiler_support/20
That isn't quite doable yet, but we can start taking advantage of language features in the meantime. More of these will be supported in older toolchains.
Anyone needing support for older C++ versions can lag behind on more recent changes. E.g. Yoga 2.0 supports C++ 14.
bypass-github-export-checks
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D49261607
fbshipit-source-id: ceb06eac20dfe93352d7b796d6847a7314069cf3
