Summary:
Bitfield enums are not sequential, so use of these functions on these enums would be invalid.
I looked at whether we could trivially move `bitCount` to template based on `ordinalCount`. `bitCount` must be constexpr, since we use it directly as a bit-field size constant. `log2` and `ceil` to be constexpr, which isn't here until C++ 26.
Reviewed By: javache
Differential Revision: D51518899
fbshipit-source-id: 256f15bbed517be6f90bf43baa43ce96e9259a71
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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1451
X-link: https://github.com/facebook/react-native/pull/41327
The special meaning of `0.0` is now explained in the function header, and we aren't doing any sort of insensitive compare here, so the code after should be equivalent and a bit simpler.
Reviewed By: yungsters
Differential Revision: D51014264
fbshipit-source-id: 60f4a2df039f74089d5c7fabd4b7d8ac6234ba72
Summary:
X-link: https://github.com/facebook/react-native/pull/41317
Pull Request resolved: https://github.com/facebook/yoga/pull/1449
This aims to clean up the public Yoga C API, by:
1. Documenting public YGNode, YGValue, YGConfig APIs
2. Splitting APIs for specific objects into different header files (because Yoga.h was big enough without documentation)
3. Reordering headers and definitions for consistent grouping
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50963424
fbshipit-source-id: 45124b7370256fc63aefd6d5b7641466e9a79d3b
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/41305
Pull Request resolved: https://github.com/facebook/yoga/pull/1448
This should not be part of Yoga's API. If benchmarks want to do this, they still can (though I don't know the ones we have for it are super valuable).
Reviewed By: javache
Differential Revision: D50963933
fbshipit-source-id: 6482bd269928188b6469a358ffde5c4f9f5f9527
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:
X-link: https://github.com/facebook/react-native/pull/41209
Pull Request resolved: https://github.com/facebook/yoga/pull/1439
There are so many instances in this code base where we use the double negative of `!yoga::isUndefined(<something>)`. This is not as easy to read since because of this double negative imo. Additionally, sometimes we have really long chains like `!longVariableName.longFunctionName(longArgumentName).isUndefined()` and it is hard to see that this undefined is inverted.
This just replaces all instances of inverted `isUndefined()` with `isDefined()` so its easier to read.
Reviewed By: NickGerleman
Differential Revision: D50705523
fbshipit-source-id: edc7d3f2cbbae38ddaeb2030a419320caf73feff
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1437
X-link: https://github.com/facebook/react-native/pull/41208
Reading through the sizing logic and this seemed a bit redundant/confusing. Lets use the same function we just used for the main axis for the cross axis as well so people do not think its special. Also we will need one less variable. The reason this was done it seems is because we need the leading padding + border elsewhere so this is technically a few less steps but this is cleaner
Reviewed By: NickGerleman
Differential Revision: D50704177
fbshipit-source-id: 1a091edbfee6482a2bf472aca2980702bd75ad94
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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1431
X-link: https://github.com/facebook/react-native/pull/41041
The last of the row-reverse issues hurray!
The position insets were broken with row-reverse since we were using the main-start/main-end edges to inset from and NOT the inline-start/inline-end edges as we should. This made it so that inset in left and right were swapped and same with top and bottom (with column-reverse). The solution here is the same as the previous ones were we are migrating to using inline-start/end as the leading/trailing edge now.
Reviewed By: NickGerleman
Differential Revision: D50390543
fbshipit-source-id: b714deab8489fbe11f7f6db21e4aad3b3aa314b3
Summary:
X-link: https://github.com/facebook/react-native/pull/41044
The reference Clang/GCC build has a pretty strict set of warnings enabled. The reference MSVC build has less strict warnings, which can be a problem for MSVC users building at higher warning levels (e.g. React Native for Windows in OSS uses `/W4` as its baseline warning level).
This bumps up the MSVC warning level to `/W4`, since we are nearly clean already.
There are some limitations. E.g. we don't test binary with MSVC (some issues I didn't work out), and only test building statically linked. But but we do have a minimal C benchmark we compile with MSVC.
Pull Request resolved: https://github.com/facebook/yoga/pull/1432
Test Plan: GitHub Actions running benchmark MSVC build.
Reviewed By: yungsters
Differential Revision: D50398443
Pulled By: NickGerleman
fbshipit-source-id: 6616034d79b1a308b32d5d3387bae70f40b7b5ab
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:
X-link: https://github.com/facebook/react-native/pull/41023
Pull Request resolved: https://github.com/facebook/yoga/pull/1426
Just like D50140503 where marginStart and marginEnd were not working with row reverse, paddingStart and paddingEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of padding (and also border) there is a callsite that actually wants to get the flex item layout's leading/trailing padding and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348995
fbshipit-source-id: 85717df23de7cf5f66b38d3ff28435b053a4e68e
Summary:
X-link: https://github.com/facebook/react-native/pull/41022
Pull Request resolved: https://github.com/facebook/yoga/pull/1425
Just like D50140503 where marginStart and marginEnd were not working with row reverse, borderStart and borderEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of border (and also padding) there is a callsite that actually wants to get the flex item layout's leading/trailing border and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348085
fbshipit-source-id: eca2702c1753dbebb503034e2f0732684ad6c56e
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1423
X-link: https://github.com/facebook/react-native/pull/41017
Before resolving https://github.com/facebook/yoga/issues/1208 yoga was in a state where "leading" and "trailing" only referred to the main-start and main-end directions ([definition in spec](https://drafts.csswg.org/css-flexbox/#box-model)). That is, the start/end of the layout of flex items in a container. This is distinct from something like inline-start/inline-end which is the [start of text layout as defined by direction](https://drafts.csswg.org/css-writing-modes-3/#inline-start).
The bug linked above happened because "leading" and "trailing" functions are referring to the wrong directions in certain cases. So in order to fix this we added a new set of functions to get the "leading" and "trailing" edges according to what inline-start/inline-end would refer to - i.e. those defined by the direction (ltr | rtl). In this state I think it is confusing to understand which function refers to which direction and more specific names could help that.
This diff just renames the following 4 FlexDirection.h functions:
* **leadingEdge** -> **flexStartEdge**
* **trailingEdge** -> **flexEndEdge**
* **leadingLayoutEdge** -> **inlineStartEdge**
* **trailingLayoutEdge** -> **inlineEndEdge**
The spec calls the start/end directions as dictated by the flex-direction attribute "main-start" and "main-end" respectively, but mainStartEdge might be a bit confusing given it will be compared to a non-flexbox-specific name in inlineStartEdge. As a result I landed on flexStart/flexEnd similar to what values are used with alignment attributes (justify-content, align-content).
I chose to get rid of the "leading" and "trailing" descriptors to be more in line with what terminology the spec uses.
Next diff will be to rename the functions in Node.cpp to adhere to the above patterns.
Reviewed By: NickGerleman
Differential Revision: D50342254
fbshipit-source-id: 1e83a885876af9cf363822ebdbb64537f4784520
Summary:
X-link: https://github.com/facebook/litho/pull/962
X-link: https://github.com/facebook/react-native/pull/40804
Pull Request resolved: https://github.com/facebook/yoga/pull/1420
This stack is ultimately aiming to solve https://github.com/facebook/yoga/issues/1208
**The problem**
Turns out that we do not even check direction when determining which edge is the leading (start) and trailing (end) edges. This is not how web does it as the start/end is based on the writing direction NOT the flex direction: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_flexible_box_layout/Basic_concepts_of_flexbox#start_and_end_lines. While web does not have marginStart and marginEnd, they do have margin-inline-start/end which relies on the writing mode to determine the "start"/"end": https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start.
This means that if you do something like
```
export default function Playground(props: Props): React.Node {
return (
<View style={styles.container}>
<View style={styles.item} />
</View>
);
}
const styles = StyleSheet.create({
container: {
marginEnd: 100,
flexDirection: 'row-reverse',
backgroundColor: 'red',
display: 'flex',
width: 100,
height: 100,
},
item: {
backgroundColor: 'blue',
width: 10,
},
});
```
You get {F1116264350}
As you can see the margin gets applied to the left edge even thought the direction is ltr and it should be applied to the right edge.
**The solution**
I ended up fixing this by creating a new `leadingLayoutEdge` and `trailingLayoutEdge` function that take the flex direction as well as the direction. Based on the errata, the a few functions will use these new functions to determine which `YGEdge` is the starting/ending.
You might be wondering why I did not put this logic inside of `leadingEdge(flexDirection)` / `trailingEdge(flexDirection)` since other areas could potentially have the same bug like `getLeadingPadding`. These functions are a bit overloaded and there are cases where we actually want to use the flexDirection to get the edge in question. For example, many of the calls to `setLayoutPosition` in `CalculateLayout.cpp` call `leadingEdge()` / `trailingEdge()` to set the proper position for cases like row-reverse where items need to line up in a different direction.
Reviewed By: NickGerleman
Differential Revision: D50140503
fbshipit-source-id: 5b580c7570f6ae1e2d031971926ac4e8f52dd362
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
Summary:
X-link: https://github.com/facebook/react-native/pull/39595
Pull Request resolved: https://github.com/facebook/yoga/pull/1404
These functions all ensure their returns are defined, but return FloatOptional anyway, making their callers have to deal with that possibility. Return `float` instead of `FloatOptional`, and do some additional cleanup.
Reviewed By: rshest
Differential Revision: D49531421
fbshipit-source-id: 95b21cade74e501dd54c7b6ca667c8c3859c5dae
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
