Summary: Was reading https://yogalayout.com/docs/aspect-ratio and noticed a typo. "Flexbox does has" -> "Flexbox does have"
Reviewed By: NickGerleman
Differential Revision: D49885138
fbshipit-source-id: 847b40eda257bd0726c3992a7285ac6fa267d418
Summary:
This diff adds the ability to add 2 flags to gentest.rb that can help with debugging that I found myself wanting to use:
* The ability to suspend the script. Meaning the chrome browser will pause after running each fixture so the user can inspect elements to see if their html is as expected. Normally, the browser just redirects to the next fixture
* The ability to run a specific fixture instead of all fixtures. I found myself wanting to do this as I was changing one in the previous diff. If the user input is incorrect it just ignores it.
Hopefully this will help make debugging this script a bit easier for noobs like me :P
Reviewed By: NickGerleman
Differential Revision: D49775228
fbshipit-source-id: 29933029119ee5afc0195213df70d4d2cf881a9e
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:
X-link: https://github.com/facebook/react-native/pull/39597
Pull Request resolved: https://github.com/facebook/yoga/pull/1406
Similar in vain to D49362819, we want to stop exposing pre-resolved CompactValue, and allow enum class usage without becoming annoying.
This also simplifies gap resolution a bit. I moved this to Style, to make it clear we aren't relying on any node state. I plan to do some similar cleanup for other resolution later.
Reviewed By: rshest
Differential Revision: D49530923
fbshipit-source-id: 47b06a7301fb283acc493dba159f496159d59580
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:
X-link: https://github.com/facebook/react-native/pull/39598
Pull Request resolved: https://github.com/facebook/yoga/pull/1403
Replaces all usages of YGDimension with Dimension.
Adds `yoga::to_underlying` to act like `std::to_underlying`, added in C++ 23.
This enum is oddly only used internally, and is never an input to the public API, but it handled as any other public generated enum. Potentially some more cleanup to do there.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49475409
fbshipit-source-id: 7d4c31e8a84485baea0dab50b5cf16b86769fa07
Summary:
These were added quite a while ago, and the proprosed change doesn't really make sense to pursue, since FloatOptional is a C++ wrapper around a Float, and the public API is entirely C.
bypass-github-export-checks
Reviewed By: rshest
Differential Revision: D49476343
fbshipit-source-id: f83cc99adda75fc0dba96e063cca92510c3d2ef0
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1402
X-link: https://github.com/facebook/react-native/pull/39567
This change hides away most usages of YGDimension as an index. We do this for a couple reasons:
1. Right now the style interface may return a full array of resolved edge or dimension values, as a CompactValue. As we abstract away from CompactValue, and move towards ValuePool, this will no longer be the internal interface, and cheap to return. We instead change the interface to return a single value at once, which lets us resolve values lazily.
2. As we move internal usage to scoped enums, enums are not implicitly convertible to intergers (broadly a good thing). Hiding the enum as index prevents the need for callers to cast or convert to underlying.
Instead of making a new version of `IdxRef` for this, I converted to a more traditional setter. I will be making similar changes later for other styles, when I hide CompactValue from the public interface.
To review I would recommend filtering to changes in `xplat`, or viewing this in a single one of the OSS PRs exported. Everything apart from the below 20 files is a mirror.
{F1096792573}
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D49362819
fbshipit-source-id: 30d730d78e62f36597d43f477120f65694e51ea3
Summary:
X-link: https://github.com/facebook/react-native/pull/39485
Pull Request resolved: https://github.com/facebook/yoga/pull/1393
These were previously packed into structs to allow zero initializing all the flags at once without needing a ctor. C++ 20 has in-class member initializer support for bitfields, which makes these look more like normal member variables.
Setting enum values is a bit jank right now, due to relying on C enums which are effectively int32_t, along with GCC `-Wconversion` being a bit aggressive in needing to explicitly mask. I have some ideas to fix this later (e.g. using scoped enums internally).
bypass-github-export-checks
Changelog:
[General][Breaking] - Require C++ 20 when including renderer headers
Reviewed By: sammy-SC
Differential Revision: D49265967
fbshipit-source-id: 6ab935a866196df06e742c821f3af88eb4d18e1a
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
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1384
X-link: https://github.com/facebook/react-native/pull/39446
This adds logic to the enum generator to generate C++ style scoped enums.
This gives us a few nicities over C enums, even if both must exist:
1. We can add types and keep unsgined enums directly in bitfields
2. Style/readability
3. Avoiding implicit int conversion
Reviewed By: rozele
Differential Revision: D49267996
fbshipit-source-id: 1c41164c377b317c1fef97811c46cbc00b5a837e
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1380
X-link: https://github.com/facebook/react-native/pull/39433
Back when rolling out flex gap, we encountered a bug where gap was added to the end of the main axis when a size was not specified.
During flex line justification/sizing, we calculate the amount of space that should be in between children. We erroneously add this, even after the last child element.
For `justify-content`, this space between children is derived from free space along the axis. The only time we have free space is if we had a dimension/dimension constraint already set on the parent. In this case, the extra space added to the end of the flex line is usually never noticed, because we bound `maxLineMainDim` to container dimension constraints at the end of layout, and the error doesn't effect how any children are positioned or sized.
There was at least one screenshot test where this issue showed up though, and I was able to add a slightly different repro where we may have free space without a definite dimension by enforcing a min dimension and not stretching.
{F1091401183}
The new reference is correct, and looking back at diffs, is what this seemed to originally look like when added three years ago. Seems like there may have been a potential regression, but I didn't spot anything suspicious when I looked around the code history.
`betweenMainDim` may still be set for `gap` even if we don't have a sized parent, which makes the extra space propagated to `maxLineMainDim` effect parent size.
Because we were in a code freeze, I opted to have us go with a solution just effecting flex gap, instead of the right one, in case there were any side effects. This cleans up the code to use the right calculation everywhere, and fixes a separate bug, where `endOfLineIndex` and `startOfLineIndex` may not be the last/first in the line if they are out of the layout flow (absolutely positioned, or display: none_
See the original conversation on https://github.com/facebook/yoga/pull/1188
Reviewed By: javache
Differential Revision: D49260049
fbshipit-source-id: 218552c5ff938668b9f257df7a1493e13ded4d0d
Summary:
This mirrors the clang-format config used by fbsource to Yoga.
They are pretty similar, except for an annoying habit where Yoga's previous forced small functions in headers to be a a single line, so you would get a combination of multiline and single line functions next to each other which are hard to read. That is what motivated this change.
It also enforces header ordering (yay). I don't think we have any side-effect causing headers, so this should be safe.
Reviewed By: yungsters
Differential Revision: D49248994
fbshipit-source-id: 66998395e7c0158ff9d9fb1bee44e8401bdd8f21
Summary:
X-link: https://github.com/facebook/react-native/pull/39404
Pull Request resolved: https://github.com/facebook/yoga/pull/1378
We thread a config through the root node, to every function, that we don't actually use (with the exception of `canUseCachedMeasurement` in the previous diff which was passing root `pointScaleFactor`).
Since the model is currently per-node config, this only creates redundancy/confusion.
I do think we might want to make some more global/layout-pass scoped configuration in the future, but likely not with this sort of drilling.
Reviewed By: yungsters
Differential Revision: D49180385
fbshipit-source-id: 91248042df7d3cea1fc316b47b8137fcb790b521
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1379
X-link: https://github.com/facebook/react-native/pull/39403
Right now we have a `pointScaleFactor` per-node, but only ever read the one off the root node. In most cases where config is global, these will be the same, but it is possible for these to differ.
This... doesn't make much sense from an API perspective, and there are edge cases where we may want to allow laying out a subtree with a different DPI then the rest of the tree (though I think there might be other solutions to that).
We should rethink some of what is currently on config being allowed per-node (do we really need each node to be able to have a separate logger?), but this makes the model consistent in the meantime.
This change is breaking to any users relying on setting `pointScaleFactor` on the config of the root node, but not other nodes.
Reviewed By: yungsters
Differential Revision: D49181131
fbshipit-source-id: f1363ca242094f04b995fd50c1e56834d5003425
Summary:
X-link: https://github.com/facebook/react-native/pull/39402
Pull Request resolved: https://github.com/facebook/yoga/pull/1377
To avoid keeping a per-node mapping on native Yoga nodes to Java nodes, a per-layout context was added, to be able to pass information from the start of the layout, to measure functions, log functions, etc.
The way this was done was super invasive, and added quite a few private APIs used only by the JNI functions.
This change removes the context-using functions from the JNI bindings in favor of it managing its own context. Next diff removes all the cruft.
Reviewed By: javache
Differential Revision: D49179243
fbshipit-source-id: 7e4944bead864e6b73fd2208a47c5725c18ff2b0
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1375
X-link: https://github.com/facebook/react-native/pull/39400
Moves `isBaselineLayout` out of `CalculateLayout` into `Baseline.h`. This function is called by flex line justification code, which I have been looking at extracting.
Reviewed By: yungsters
Differential Revision: D49177937
fbshipit-source-id: 02c13aa0b02b26cb60ef197473b90e06d53d5f8d
Summary:
X-link: https://github.com/facebook/react-native/pull/39397
Pull Request resolved: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1374
X-link: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1372
X-link: 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:
X-link: https://github.com/facebook/react-native/pull/39374
Pull Request resolved: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1368
X-link: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1370
X-link: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1366
X-link: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1369
X-link: 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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1365
X-link: 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:
X-link: 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:
X-link: https://github.com/facebook/react-native/pull/39291
Pull Request resolved: 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:
We sometimes see workflows fail due to network flakiness, almost always being Windows agents doing a `yarn install`. This change enables storing and reusing Yarn's package cache, and makes `yarn install` more permissive when it does hit the network. https://stackoverflow.com/questions/51508364/yarn-there-appears-to-be-trouble-with-your-network-connection-retrying
Pull Request resolved: https://github.com/facebook/yoga/pull/1332
Test Plan: Workflows succeed, and we see cache being restored before yarn install step.
Reviewed By: lunaleaps
Differential Revision: D48967590
Pulled By: NickGerleman
fbshipit-source-id: 55ce6f05496f014512e0153b6646a7ca0ab964d9
Summary:
X-link: https://github.com/facebook/react-native/pull/39195
Pull Request resolved: https://github.com/facebook/yoga/pull/1352
## This diff
This splits out all of the logic under `YGNodeCalculateLayout` to a couple of different files, does some mechanical renaming, and starts to split up the implementation a tiny bit. After this, core layout functions are all C++ convention and namespaced.
Each new file is marked as a move for the sake of blame history. It means Phabricator has a very inaccurate count of lines removed though.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Reviewed By: rshest
Differential Revision: D48770478
fbshipit-source-id: 2a74b86441c3352de03ae193c98fc3a3573047ed
