Summary:
X-link: https://github.com/facebook/react-native/pull/43405
Pull Request resolved: https://github.com/facebook/yoga/pull/1592
Fixes https://github.com/facebook/yoga/issues/1590
Yoga may be built with a high warning level. This is helpful in letting Yoga be used in more places, and finding defects. We currently set these in the internal BUCK build, the CMake reference build, and the Yoga Standalone (not RN) CocoaPods build.
Yoga's reference CMake build and spec are consumed today by users of Yoga, instead of just Yoga developers. Here, it makes more sense to avoid anything that could break compiler-to-compiler compatibility.
We default these to a less intense (`-Wall -Werror`). I kept `/W4`, for pragmatic reasons, and since it is relatively standard for MSVC.
We continue to build with strict flags on Buck build on Clang.
Reviewed By: cortinico
Differential Revision: D54735661
fbshipit-source-id: 130e35ac9dcffa2f7e70e48d18770f1275864e2a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1585
When used alone, yoga has no visibility over the USE_FRAMEWORKS variable set by React Native.
In this case, there is no other way to know whether the current target that will install the spec is using use_framewors or not. As a failsafe, condition, let's always add the `"$(PODS_TARGET_SRCROOT)"` to the search paths to make sure that archiving won't fail.
Whe used in other context, that should not be a problem: search paths are just directory Xcode uses to find headers that are needed.
Reviewed By: NickGerleman
Differential Revision: D54417386
fbshipit-source-id: aa2ae41c077e4346c0417c73291a37c992a06b58
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/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:
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:
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:
X-link: https://github.com/facebook/react-native/pull/39221
Pull Request resolved: https://github.com/facebook/yoga/pull/1349
X-link: https://github.com/facebook/react-native/pull/39171
## This diff
This diff adds a `style` directory for code related to storing and manipulating styles. `YGStyle`, which is not a public API, is renamed to `yoga::Style` and moved into this folder, alongside `CompactValue`. We will eventually add `ValuePool` alongside this for the next generation style representation.
## 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.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D48847261
fbshipit-source-id: 0fc8c6991e19079f3f0d55d368574757e453fe93
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1349
X-link: https://github.com/facebook/react-native/pull/39171
## This diff
This diff adds a `style` directory for code related to storing and manipulating styles. `YGStyle`, which is not a public API, is renamed to `yoga::Style` and moved into this folder, alongside `CompactValue`. We will eventually add `ValuePool` alongside this for the next generation style representation.
## 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.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D48710084
fbshipit-source-id: 20961aee30d54a6b0d8c1cc2976df09b9b6d486a
Summary:
X-link: https://github.com/facebook/react-native/pull/38303
Pull Request resolved: https://github.com/facebook/yoga/pull/1327
This bumps Yoga to C++ 17 for a few reasons:
1. New versions of C++ may introduce behavior changes (e.g. evaluation order) and deprecations. Keeping the version closer to the version of large users helps avoid that.
2. C++ 17 unblocks some new bits I have wanted to use at times, like `std::optional`, `std::variant`, `if constexpr`, `[[nodiscard]]`.
3. There are already changes in C++ 20 that would be directly useful to Yoga, like `std::bit_cast` to avoid `memcpy` style type punning.
There has been some contention around C++ versions before, but by the time the next stable version of Yoga is out, it will have been more than 6 years (~2 C++ versions) since a stable version of Clang/LLVM with C++ 17 support. I would not like to go back further than n-2.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D47383922
fbshipit-source-id: eb95d4853f2168b68d6df5fddb797236eac55870
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1307
This syncs up some of the descriptions, author names, etc between the different Yoga packages we are going to soon publish.
Reviewed By: cortinico
Differential Revision: D46664187
fbshipit-source-id: b15974efee31f349650e5d23f9fcaebaef6d6dd3
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1305
Made a quick script to set versions in manifests that currently exist. This should probably be stamped in more places, like the binary as well, but we don't do that right now. This does not update lockfiles for CocoaPods or JS, so those will need to be updated via an install after running this script.
A note on language: This repo already has too many toolchains, but I chose Python for this since it corresponds with the enum script, and we can run it with no dependencies on macOS/Linux distros.
Reviewed By: cortinico
Differential Revision: D46662378
fbshipit-source-id: 74ab99eef137511f8ed2fd7d81335a0fa633caf5
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1294
X-link: https://github.com/facebook/react-native/pull/37383
Add -Wextra to the build, and fixup some more instances of -Wunused-parameter that it sufaces which were not automatically fixable.
Reviewed By: javache
Differential Revision: D45772846
fbshipit-source-id: 29bf71006f63161521fe5869c3a7d8bf7aae9c81
Summary:
X-link: https://github.com/facebook/litho/pull/940
Pull Request resolved: https://github.com/facebook/yoga/pull/1252
X-link: https://github.com/facebook/react-native/pull/36993
Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works.
1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default)
2. Cocoapods will roll up all of the public headers when importing a module
https://github.com/facebook/react-native/pull/33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI.
The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment.
Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45139075
fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1203
~~This sets the C++ standard to C++ 17 in the working builds and Apple. GTest will stop supporting C++ 11 soon, so we need to update. C++ 14 is more embeddable, but C++ 17 support and usage should be relatively common now and the language version adds quite a bit.~~
This bumps from C++ 11 to C++ 14 in existing places where it is specified. C++ 17 allows more, and is better aligned to infra (semantics can change in std versions in suprising ways), but C++ 14 still has broader ecosystem compatibility.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D42285391
fbshipit-source-id: 88d7b6b8783a80b9b2e48781a2fd3d326ecd87d0
Summary:
This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See https://github.com/facebook/react-native/pull/33381.
The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers.
Tested in the YogaKitSample, and also in a react-native app.
Changelog:
[iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus
Pull Request resolved: https://github.com/facebook/yoga/pull/1150
Reviewed By: dmitryrykun
Differential Revision: D36966687
Pulled By: cortinico
fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39
Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.
The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.
This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.
I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.
Changelog:
[Internal] - Yoga Podspec: Export YGNore and YGStyle headers
Pull Request resolved: https://github.com/facebook/yoga/pull/997
Reviewed By: hramos
Differential Revision: D20966075
Pulled By: mdvacca
fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e
Summary:
@public
Push version to *1.14.0.*
This release contains some bug fixes around `align-content`.
Reviewed By: colriot
Differential Revision: D14833417
fbshipit-source-id: f653d5fbb36f307c92b14c091c3206290256f036
Summary: I have released a new yoga and yogakit pod with 1.12.0-pre.2
Reviewed By: davidaurelio
Differential Revision: D14722676
fbshipit-source-id: 7b379ee41d04a15e25dcb2e992f361d9403269c4
Summary:
Push version in podspec. We will use `-SNAPSHOT` for bintray
Pull Request resolved: https://github.com/facebook/yoga/pull/865
Differential Revision: D14299474
Pulled By: davidaurelio
fbshipit-source-id: e788479677e1b3c4155a24a336e625508e085f86
Summary:
Currently the CocoaPod for Yoga explicitly states platform requirements.
Since the Yoga implementation doesn't depend on any platform features, it would be safe to build it on any platform.
That can be configured by omitting the `platform`/`platforms` key:
> The platform on which this Pod is supported. Leaving this blank means the Pod is supported on all platforms.
>
> http://guides.cocoapods.org/syntax/podspec.html#platform
Among others, that would allow to use the pod in macOS projects
Pull Request resolved: https://github.com/facebook/yoga/pull/821
Reviewed By: passy
Differential Revision: D13848153
Pulled By: davidaurelio
fbshipit-source-id: 5a3e81d81ca97b120f2711bafd3c8b9e0c3f8088
Summary:
This PR adds support for using Yoga Swift dependents when Yoga is pulled as a static library.
Currently swift projects trying to pull static libraries are unable to import the module. The reason for that is because the `DEFINES_MODULES` build setting is set to`NO`. If a Swift Framework is trying to `pod spec lint --use-libraries` with `Yoga` as a dependency, the validation will fail. With the `DEFINES_MODULE` enabled, the product will be treated as defining its own module. This enables automatic production of LLVM module map files when appropriate, and allows the product to be imported as a module.
A workaround to this issue would be passing the `:modular_headers` flag to the `Podfile`, but that would not fix the `pod spec lint` validation for framework/library dependencies, it would just allow consuming applications to build and run.
An example of this issue would be [SonarKit](https://github.com/facebook/Sonar/blob/master/iOS/SonarKit.podspec). `SonarKit` wasn't able to validate its podspec due to `YogaKit` (Swift Framework) depending on `Yoga` and SonarKit validating with the `--use-libraries` flag due to the c++ dependencies. We had to create a new version of [Yoga 1.9 podspec](https://github.com/facebook/Sonar/blob/master/Specs/Yoga/1.9/Yoga.podspec.json) and make sure to set the `DEFINES_MODULE` flag of the pod target. After that, we were able to `pod spec lint` `SonarKit.podspec` successfully.
After merging a new `tag` should be created and the new podspec should be pushed to cocoapods master repository.
Pull Request resolved: https://github.com/facebook/yoga/pull/793
Reviewed By: passy
Differential Revision: D8820126
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 98eae3c31ec67a03c0fe97e05ab9e79446fa9f78
Summary: Fix yoga podspec issue. The newly released versiong of Yoga i.e 1.8.0 was not building on iOS. So fixing the bug. Want to use this pod in SonarKitLayout
Reviewed By: emilsjolander
Differential Revision: D8024641
fbshipit-source-id: c8d7279e654145199fbee6655909e1c10d8b2114
Summary:
Podspec to push yoga 1.8.0 to cocoapods. There is an issue with cocoapods and it fails to lint those projects with C++ in its header, which is the case with yoga too.
Follow this thread https://github.com/CocoaPods/CocoaPods/issues/5152. To make the lint pass, one would have to change `app_target_helper.rb` cocoapod source file in the local machine. Follow my [gist](https://gist.github.com/priteshrnandgaonkar/dcca9639a3bc0a3b9adecae3a2b3b0c4).
I am able to pass the lint, but not able to push the pod in cocoapods as I am not the admin. @[759512522:emilsj], please push it on Cocoapods or give me permission.
Podspec now also exposes public header explicitly.
Reviewed By: gkassabli
Differential Revision: D7375018
fbshipit-source-id: 4e82e1c0b6340c3f8d3b8a96ecadbcb711d4bcd8
Summary: Changed the extensions of c files to cpp and made the project build successfully
Reviewed By: gkassabli
Differential Revision: D6271299
fbshipit-source-id: 66c0e54ccf019d72d1fd0b4d117826e4e84fdc89
Summary: Make the two podspecs more consistent with each other.
Reviewed By: dshahidehpour
Differential Revision: D4481945
fbshipit-source-id: ab782abecd709c763b4e931b6839a5cae6346281
Summary: This is the first step to adding cocoapods support to YogaKit. We are going to publish a `Yoga` framework to the store that we can use as a dependency. This will also allow developers to build their own abstractions easily using the core API.
Reviewed By: nlutsenko, emilsjolander
Differential Revision: D4466788
fbshipit-source-id: 8f08bdbf524e57c88f7fc3400c4ba6ad58f98d7f
