lp:folly

Created by Sam Spilsbury on 2013-05-10 and last modified on 2019-03-21
Get this branch:
bzr branch lp:folly

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Sam Spilsbury
Project:
folly
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://github.com/facebook/folly.git.

The next import is scheduled to run in 2 hours.

Last successful import was 3 hours ago.

Import started 3 hours ago on izar and finished 3 hours ago taking 20 seconds — see the log
Import started 9 hours ago on alnitak and finished 9 hours ago taking 20 seconds — see the log
Import started 15 hours ago on alnitak and finished 15 hours ago taking 25 seconds — see the log
Import started 21 hours ago on izar and finished 21 hours ago taking 20 seconds — see the log
Import started on 2019-03-20 on izar and finished on 2019-03-20 taking 20 seconds — see the log
Import started on 2019-03-20 on alnitak and finished on 2019-03-20 taking 20 seconds — see the log
Import started on 2019-03-20 on alnitak and finished on 2019-03-20 taking 20 seconds — see the log
Import started on 2019-03-19 on alnitak and finished on 2019-03-19 taking 25 seconds — see the log
Import started on 2019-03-19 on alnitak and finished on 2019-03-19 taking 20 seconds — see the log
Import started on 2019-03-19 on alnitak and finished on 2019-03-19 taking 20 seconds — see the log

Recent revisions

6825. By Andrii Grynenko <email address hidden> 17 hours ago

Update README

Reviewed By: lewissbaker

Differential Revision: D14554480

fbshipit-source-id: 1aea2bf01d69550d0cdb68fc61d22b2c0e42664e

6824. By Eric Niebler <email address hidden> on 2019-03-20

executor wrappers don't take extra schedule parameters

Summary: The type-erasing executor wrappers and the generic executor wrappers accept extra parameters to their `schedule` member functions, but nowhere is that functionality used, and such executor types would fail to satisfy the Executor concepts anyway. Remove that functionality.

Reviewed By: kirkshoop

Differential Revision: D14541290

fbshipit-source-id: 8cf0fd7bdc6dea72e43d5decc9e70ba843ab2db8

6823. By Joe Loser <email address hidden> on 2019-03-20

Fix bootstrap-osx-homebrew.sh to work with CMake builds (#1041)

Summary:
- The `bootstrap-osx-homebrew.sh` script is out of date. It previously
  worked when Folly used Autotools, but was not updated when CMake
  replaced Autotools for the build system.
- Update dependencies to install.
- Do not export environment variables when it is not needed; simply pass the
  defines needed directly to the `cmake` invocation.
- Update `README.md` to specify correct dependencies with CMake build
  for both Homebrew and Macports.

Closes #1038
Pull Request resolved: https://github.com/facebook/folly/pull/1041

Reviewed By: yfeldblum

Differential Revision: D14293767

Pulled By: calebmarchent

fbshipit-source-id: 4c53fa105e009090c80690eca8beb5a8c1491a48

6822. By Caleb Marchent <email address hidden> on 2019-03-20

New folly_test_util library for functions used by other projects (#1071)

Summary:
LogDevice uses DeterministicSchedule and JsonTestUtil from Folly make
these available in the installed library targets so that LogDevice can
compile against installed folly rather than referencing sources
directly.
Pull Request resolved: https://github.com/facebook/folly/pull/1071

Reviewed By: yfeldblum

Differential Revision: D14531954

Pulled By: calebmarchent

fbshipit-source-id: 9bd343210451ad6b2e171c6ddddb7d8677fa6290

6821. By Rob Sherwood <email address hidden> on 2019-03-20

Tweak the OSS gflags dependency inference logic

Summary:
The current logic for "which gflags library should we use" checks for
the first library (e.g., libgflags vs. libgflags-shared) listed as a TARGET.
Unfortunately, on some number of systems, the gflags-config.cmake (read:
the file that is supposed to tell you how to use gflags with cmake) actually
defines (but doesn't use!) libraries that don't exist (!) so this logic breaks.

Instead, use the system defined gflags_LIBRARIES variable which explicitly
tells us which library to use.

Reviewed By: yfeldblum, simpkins

Differential Revision: D14512966

fbshipit-source-id: add4ecf6bade502b2d12aad2bdfcf0476eeba465

6820. By Yedidya Feldblum <email address hidden> on 2019-03-19

Fix odd UserMetric design in folly/Benchmark.h

Summary: [Folly] Fix odd `UserMetric` design in `folly/Benchmark.h`.

Reviewed By: phoad

Differential Revision: D14494202

fbshipit-source-id: c1be1d9b5bdfe07677713ef00401c85270bbe627

6819. By Lewis Baker <email address hidden> on 2019-03-19

Add variadic folly::coro::collectAlll() and collectAllTry()

Summary:
Adds two new functions to folly::coro for concurrently awaiting a fixed number of sub-tasks.

* `folly::coro::collectAll(tasks...)`
* `folly::coro::collectAllTry(tasks...)`

Both can be used to concurrently await multiple input tasks. The difference is in how they report the results.

`collectAll()` produces a tuple of the result values for each of the input operations. If any of the input operations fails with an exception then the whole operation fails with an exception (which one is unspecified) any successful results are discarded.

`collectAllTry()` produces a tuple of `Try<T>` objects regardless of whether any of the input operations failed with an exception. The individual result objects can then be queried for the success/failure, allowing the caller to handle partial failure and/or determine which operation(s) failed.

Reviewed By: andriigrynenko

Differential Revision: D14334714

fbshipit-source-id: 22eb51e2198be42e77677a066bfbc15e1c7eb7dd

6818. By deryck <deryck@deryck-hp> on 2019-03-19

moved FOLLY_HAVE_SENDMMSG to FollyConfigChecks.cmake for issue #1011 (#1053)

Summary:
Compile error on Linux 2.6.32-754.6.3.el6.x86_64 /gcc 7.4/NetOps.cpp (issue #1011)
Pull Request resolved: https://github.com/facebook/folly/pull/1053

Reviewed By: Orvid

Differential Revision: D14454590

Pulled By: yfeldblum

fbshipit-source-id: 9c4dccfa30291dd0fb830cc2417c17568ae4fde3

6817. By Matthieu Martin <email address hidden> on 2019-03-19

Provide executor getter for ExecutorLoopController

Summary: This change enables to acquire the executor from the current FiberManager when using ExecutorLoopController (which is already possible to do with the EventBase's loop controller).

Reviewed By: andriigrynenko

Differential Revision: D14515799

fbshipit-source-id: 3b9e48450bf58ea94bebab50dbbcfd7720f90d61

6816. By Joe Loser <email address hidden> on 2019-03-19

Set CMake policy CMP0075 to respect CMAKE_REQUIRED_LIBRARIES (#1066)

Summary:
- For CMake 3.12 and above, CMP0075 is available which allows the macro
  `check_include_file`, `check_include_files`, and `check_include_files_cxx`
  to prefer to link the check executable to the libraries listed in the
  `CMAKE_REQUIRED_LIBRARIES` variable.
- For CMake 3.13.4, not having this policy set results in a warning such
  as the one below.

```
CMake Warning (dev) at /usr/local/Cellar/cmake/3.14.0/share/cmake/Modules/CheckIncludeFileCXX.cmake:79 (message):
  Policy CMP0075 is not set: Include file check macros honor
  CMAKE_REQUIRED_LIBRARIES. Run "cmake --help-policy CMP0075" for policy
  details. Use the cmake_policy command to set the policy and suppress this
  warning.

  CMAKE_REQUIRED_LIBRARIES is set to:

    Threads::Threads;gflags_shared;/usr/lib/libssl.dylib;/usr/local/Cellar/openssl/1.0.2q/lib/libcrypto.dylib

  For compatibility with CMake 3.11 and below this check is ignoring it.
Call Stack (most recent call first):
  CMake/folly-deps.cmake:144 (CHECK_INCLUDE_FILE_CXX)
  CMakeLists.txt:90 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
```

- This patch sets the policy to the new behavior which means we will
  honor `CMAKE_REQUIRED_LIBRARIES` in the include file check macros now.
- The warning is now gone for those using CMake 3.13.4 or later.
Pull Request resolved: https://github.com/facebook/folly/pull/1066

Reviewed By: Orvid

Differential Revision: D14500811

Pulled By: yfeldblum

fbshipit-source-id: 767bafbc6e15099a85cd0a5556e7f50f7c4fd0eb

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers