Summary:
[Folly] Cut `FOLLY_CACHE_LINE_SIZE` macro, replacing uses with `folly::hardware_destructive_interference_size`.

As one oddity, `FOLLY_CACHE_LINE_SIZE` had value 64 while `folly::hardware_destructive_interference_size` has value 128, so some types may get larger.

Reviewed By: aary

Differential Revision: D14574695

fbshipit-source-id: 7c5b9e313c5dcdecfec3cc47ec7bd55d08ae762c

Summary:
Add combined critical sections to DistributedMutex.  The implementation uses
the framework within DistributedMutex as the point of reference for contention
and resolves contention by either combining the lock requests of peers or
migrating the lock based on usage and internal state.  This boosts the
performance of DistributedMutex more than before - up to 4x relative to the
old benchmark on dual socket Broadwell and up to 5x on single socket Skylake
machines.  The win might be bigger when the cost of mutex migration is higher,
eg.  when the data being protected is wider than a single L1 cache line.
Small critical sections when used in combinable mode, can now go more than 10x
faster than the small locks, about 6x faster than std::mutex, up to 2-3x
faster than the implementations of flat combining we benchmarked against and
about as fast as a CAS instruction/loop (faster on some NUMA-less and more
parallel architectures like Skylake).  This also allows flat combining to be
used in situations where fine-grained locking would be beneficial with
virtually no overhead, DistributedMutex retains the original size of 8 bytes.
DistributedMutex resolves contention through flat combining up to a constant
factor of 2 contention chains to prevent issues with fairness and latency
outliers.  So we retain the fairness benefits of the original implementation
with no noticeable regression when switching between the lock methods.

The implementation of combined critical sections here is different from the
original flat combining paper.  This uses the same stack based LIFO contention
chains from DistributedMutex to allow the leader to resolve lock requests from
peers.  Combine records are located on the stack along with the wait-node as an
InlineFunctionRef instance to avoid memory allocation overhead or expensive
copying.  Using InlineFunctionRef also means that function calls are resolved
without having to go through the double lookup of a vtable based implementation.
InlineFunctionRef can flatten the virtual table and callable object in-situ
so we have just one indirection.  Additionally, we use preemption as a signal
to speed up lock requests in the case where latency of acquisition would have
otherwise gone beyond our control.  As a side-bonus, this also results in much
simpler code.

The API looks like the following
```
auto integer = std::uint64_t{};
auto mutex = folly::DistributedMutex{};

// ...

mutex.lock_combine([&]() {
  foo();
  integer++;
});
```

This adds three new methods for symmetry with the old lock functions
- folly::invoke_result_t<const Func&> lock_combine(Func) noexcept;
- folly::Optional<> try_lock_combine_for(duration, Func) noexcept;
- folly::Optional<> try_lock_combine_until(time_point, Func) noexcept;

Benchmarks on Broadwell
```
std_mutex_simple(1thread)                                  617.28ns    1.62M
google_spin_simple(1thread)                      101.97%   605.33ns    1.65M
folly_microspin_simple(1thread)                   99.40%   621.01ns    1.61M
folly_picospin_simple(1thread)                   100.15%   616.36ns    1.62M
folly_microlock_simple(1thread)                   98.86%   624.37ns    1.60M
folly_sharedmutex_simple(1thread)                 86.14%   716.59ns    1.40M
folly_distributedmutex_simple(1thread)            97.95%   630.21ns    1.59M
folly_distributedmutex_flatcombining_simple(1th   98.04%   629.60ns    1.59M
folly_flatcombining_no_caching_simple(1thread)    89.85%   687.01ns    1.46M
folly_flatcombining_caching_simple(1thread)       78.36%   787.75ns    1.27M
atomics_fetch_add(1thread)                        97.88%   630.67ns    1.59M
atomic_cas(1thread)                              102.31%   603.33ns    1.66M
----------------------------------------------------------------------------
std_mutex_simple(2thread)                                    1.14us  875.72K
google_spin_simple(2thread)                      125.08%   912.95ns    1.10M
folly_microspin_simple(2thread)                  116.03%   984.14ns    1.02M
folly_picospin_simple(2thread)                   117.35%   973.04ns    1.03M
folly_microlock_simple(2thread)                  102.54%     1.11us  897.95K
folly_sharedmutex_simple(2thread)                121.04%   943.42ns    1.06M
folly_distributedmutex_simple(2thread)           128.24%   890.48ns    1.12M
folly_distributedmutex_flatcombining_simple(2th  107.99%     1.06us  945.66K
folly_flatcombining_no_caching_simple(2thread)    83.40%     1.37us  730.33K
folly_flatcombining_caching_simple(2thread)       87.47%     1.31us  766.00K
atomics_fetch_add(2thread)                       115.71%   986.85ns    1.01M
atomic_cas(2thread)                              171.35%   666.42ns    1.50M
----------------------------------------------------------------------------
std_mutex_simple(4thread)                                    1.98us  504.43K
google_spin_simple(4thread)                      103.24%     1.92us  520.76K
folly_microspin_simple(4thread)                   92.05%     2.15us  464.33K
folly_picospin_simple(4thread)                    89.16%     2.22us  449.75K
folly_microlock_simple(4thread)                   66.62%     2.98us  336.06K
folly_sharedmutex_simple(4thread)                 82.61%     2.40us  416.69K
folly_distributedmutex_simple(4thread)           108.83%     1.82us  548.98K
folly_distributedmutex_flatcombining_simple(4th  145.24%     1.36us  732.63K
folly_flatcombining_no_caching_simple(4thread)    84.77%     2.34us  427.62K
folly_flatcombining_caching_simple(4thread)       91.01%     2.18us  459.09K
atomics_fetch_add(4thread)                       142.86%     1.39us  720.62K
atomic_cas(4thread)                              223.50%   887.02ns    1.13M
----------------------------------------------------------------------------
std_mutex_simple(8thread)                                    3.70us  270.40K
google_spin_simple(8thread)                      110.24%     3.35us  298.09K
folly_microspin_simple(8thread)                   81.59%     4.53us  220.63K
folly_picospin_simple(8thread)                    57.61%     6.42us  155.77K
folly_microlock_simple(8thread)                   54.18%     6.83us  146.49K
folly_sharedmutex_simple(8thread)                 55.44%     6.67us  149.92K
folly_distributedmutex_simple(8thread)           109.86%     3.37us  297.05K
folly_distributedmutex_flatcombining_simple(8th  225.14%     1.64us  608.76K
folly_flatcombining_no_caching_simple(8thread)    96.25%     3.84us  260.26K
folly_flatcombining_caching_simple(8thread)      108.13%     3.42us  292.39K
atomics_fetch_add(8thread)                       255.40%     1.45us  690.60K
atomic_cas(8thread)                              183.68%     2.01us  496.66K
----------------------------------------------------------------------------
std_mutex_simple(16thread)                                   8.70us  114.89K
google_spin_simple(16thread)                     124.47%     6.99us  143.01K
folly_microspin_simple(16thread)                  86.46%    10.07us   99.34K
folly_picospin_simple(16thread)                   40.76%    21.36us   46.83K
folly_microlock_simple(16thread)                  54.78%    15.89us   62.94K
folly_sharedmutex_simple(16thread)                58.14%    14.97us   66.80K
folly_distributedmutex_simple(16thread)          124.53%     6.99us  143.08K
folly_distributedmutex_flatcombining_simple(16t  324.08%     2.69us  372.34K
folly_flatcombining_no_caching_simple(16thread)  134.73%     6.46us  154.79K
folly_flatcombining_caching_simple(16thread)     188.24%     4.62us  216.28K
atomics_fetch_add(16thread)                      340.07%     2.56us  390.72K
atomic_cas(16thread)                             220.15%     3.95us  252.93K
----------------------------------------------------------------------------
std_mutex_simple(32thread)                                  25.62us   39.03K
google_spin_simple(32thread)                     105.21%    24.35us   41.07K
folly_microspin_simple(32thread)                  79.64%    32.17us   31.08K
folly_picospin_simple(32thread)                   19.61%   130.67us    7.65K
folly_microlock_simple(32thread)                  42.97%    59.62us   16.77K
folly_sharedmutex_simple(32thread)                52.41%    48.88us   20.46K
folly_distributedmutex_simple(32thread)          144.48%    17.73us   56.39K
folly_distributedmutex_flatcombining_simple(32t  461.73%     5.55us  180.22K
folly_flatcombining_no_caching_simple(32thread)  207.55%    12.34us   81.01K
folly_flatcombining_caching_simple(32thread)     237.34%    10.80us   92.64K
atomics_fetch_add(32thread)                      561.68%     4.56us  219.23K
atomic_cas(32thread)                             484.13%     5.29us  188.96K
----------------------------------------------------------------------------
std_mutex_simple(64thread)                                  31.26us   31.99K
google_spin_simple(64thread)                      99.95%    31.28us   31.97K
folly_microspin_simple(64thread)                  83.63%    37.38us   26.75K
folly_picospin_simple(64thread)                   20.88%   149.68us    6.68K
folly_microlock_simple(64thread)                  45.46%    68.77us   14.54K
folly_sharedmutex_simple(64thread)                52.65%    59.38us   16.84K
folly_distributedmutex_simple(64thread)          154.90%    20.18us   49.55K
folly_distributedmutex_flatcombining_simple(64t  475.05%     6.58us  151.96K
folly_flatcombining_no_caching_simple(64thread)  195.63%    15.98us   62.58K
folly_flatcombining_caching_simple(64thread)     199.29%    15.69us   63.75K
atomics_fetch_add(64thread)                      580.23%     5.39us  185.61K
atomic_cas(64thread)                             510.76%     6.12us  163.39K
----------------------------------------------------------------------------
std_mutex_simple(128thread)                                 70.53us   14.18K
google_spin_simple(128thread)                     99.20%    71.09us   14.07K
folly_microspin_simple(128thread)                 88.73%    79.49us   12.58K
folly_picospin_simple(128thread)                  22.24%   317.06us    3.15K
folly_microlock_simple(128thread)                 50.17%   140.57us    7.11K
folly_sharedmutex_simple(128thread)               59.53%   118.47us    8.44K
folly_distributedmutex_simple(128thread)         172.74%    40.83us   24.49K
folly_distributedmutex_flatcombining_simple(128  538.22%    13.10us   76.31K
folly_flatcombining_no_caching_simple(128thread  165.11%    42.72us   23.41K
folly_flatcombining_caching_simple(128thread)    161.46%    43.68us   22.89K
atomics_fetch_add(128thread)                     606.51%    11.63us   85.99K
atomic_cas(128thread)                            578.52%    12.19us   82.03K
```

Reviewed By: djwatson

Differential Revision: D13799447

fbshipit-source-id: 923cc35e5060ef79b349690821d8545459248347

Summary:
- CMake 3.9 or later has the `GoogleTest` module which allows for the
  ability to automatically add tests to CTest by scanning the source code
  for Google Test Macros. This is used in `CMake/FollyFunctions.cmake`.
  However, this scanning is just exact string search without full context.
  So, this flags a comment in  `FBStringTest.cpp`. As a result, it tries to
  register the comment matching the macro as a new test. Since the comment
  matches an exact test case which has already been defined, this results in
  a hard error as you cannot have two test cases of the same name in the same
  test suite. The error is as follows:

```
  add_test given test NAME "fbstring_test.FBString.testMoveCtor" which
  already exists in this directory.
Call Stack (most recent call first):
  CMake/FollyFunctions.cmake:268 (gtest_add_tests)
  CMakeLists.txt:481 (folly_define_tests)
```

- Fix the comment to keep the same intent but not get treated as a test
  registration.
Pull Request resolved: https://github.com/facebook/folly/pull/1080

Differential Revision: D14613558

Pulled By: yfeldblum

fbshipit-source-id: 74ebef0ba9a8690ff8f3dfd4cd049f72114ef9a5

Summary: [Folly] Disable `gcc < 5` via compile-time error.

Reviewed By: mzlee

Differential Revision: D14590065

fbshipit-source-id: 3d184f58f6b2f2d616092255002a95e96c7bc31c

Summary: Needed if a downstream project needs to compile against Deterministic schedule; which is now a part of the folly_test_util library.

Reviewed By: Orvid

Differential Revision: D14597430

fbshipit-source-id: 84f590640a32cb71d8c9422ff5a32ba5e71585e6

Summary: [Folly] Enable `fbstring` test in cmake builds. Fix an msvc build failure which would otherwise prevent enabling this test.

Reviewed By: Orvid

Differential Revision: D14595828

fbshipit-source-id: fbc2109830f2b085dffa33d8e61cd7c5e14b1215

Summary:
Copyright header was missing from cmake files and Open Source Bot complained
about it. Adding header to be compliant with our oss policies

Reviewed By: yns88

Differential Revision: D14603978

fbshipit-source-id: fab9e781969e10038537ebbdab87b1272f093bf1

Summary: Fix race condition due to missed notification

Reviewed By: ddrcoder

Differential Revision: D14595289

fbshipit-source-id: d2be3da5a3de6c76fb2ef1d2b4274f6737c92c22

Summary: Now that the APIs are backed by NetworkSocket, most of the header is no longer required.

Reviewed By: yfeldblum

Differential Revision: D14594696

fbshipit-source-id: 40ff90e18a4d6ff7d1a9a48aac4d4931c84a362d

Summary: These should be being created via the socket file descriptor map, not out on it's own.

Reviewed By: yfeldblum

Differential Revision: D14594655

fbshipit-source-id: 46cf5d5aa4e05b1235af396656cbd156eed46aed

Summary:
Add a test that verifies that the compiler does not issue a
warning/error complaining about a discarded return-value.

Reviewed By: yfeldblum

Differential Revision: D14546568

fbshipit-source-id: 98b479da78b01549b5cec2893fc3e454ba3bb802

Summary: Fix broken opt folly build (-Werror,-Wunused-variable)

Reviewed By: yfeldblum

Differential Revision: D14593419

fbshipit-source-id: 5f298a2517fecfb33f8acf37b7d5ab9f714c934c

Summary:
[Folly] Fix incorrect `forward_tuple` test which only passes with libc++ < 3.8 and libstdc++ < 8.

The test would fail with libc++ >= 3.8 and with libstdc++ >= 8.

Spec fix in: https://cplusplus.github.io/LWG/issue2485.
Upstream libc++ fix in: https://github.com/llvm-mirror/libcxx/commit/199bee0ea7750b8e96a25414c3c2a7b465336e36.
Upstream libstdc++ fix in: https://github.com/gcc-mirror/gcc/commit/6d8efcd444067c046d72ac8e11737230f031a031.

Closes #1078.

Reviewed By: pixelb

Differential Revision: D14590323

fbshipit-source-id: ff023ab844d5da97e83f09576897304ac06678b8

Summary: [Folly] Fix `Conv.stdChronoToTimespec` test on macOS.

Reviewed By: simpkins

Differential Revision: D14575684

fbshipit-source-id: e0a0dfb89a17eaa5d83e1906f5d92112ab2b5b22

Summary:
Use the watchman cmake files to seed the common cmake library and adjust
a number of our opensource projects to take their glog and gflags module
finding from that central location.

Note that there are a variety of ad-hoc re-implementations of shipit in various build scripts used in sandcastle jobs at the moment that result in adding multiple cmake module paths to correctly locate the shared cmake directory.  The long term solution is to get all those projects integrated in the new fbcode_builder stuff that I'm working on.

Reviewed By: simpkins, calebmarchent

Differential Revision: D14549654

fbshipit-source-id: e49a7f20a15af52b4b3ed3037b8973fc293656dc

Summary:
Now that we have `.schedule()`, We can syntactically determine what things are executors and which are not. We can also tell what kind of executor, be it constrained, or time, or neither. Therefore, we no longer need the `is_executor<>` property query. Nuke it.

In addition, all the `Sender`, `Receiver`, and `Executor` concepts, in addition to testing for the required syntac, took an arbitrary number of properties to query. Those were breaking subsumption relationships (e.g., `Sender<From, is_many<>>` doesn't subsume `Sender<From>`). Move those property queries out of the concept heirarchy and into separate algorithm requirements that test the properties directly.

Reviewed By: kirkshoop

Differential Revision: D14570712

fbshipit-source-id: 8ae0d96e5c9f00dcea3fbff4bbbe04c71bb0df07

Summary: Several of the pushmi examples needed a working thread pool. Use the new one in pushmi/examples/pool.h, and bring the examples up-to-date with recent pushmi changes.

Reviewed By: yfeldblum

Differential Revision: D14563479

fbshipit-source-id: 70def2adc90fdf3eb5eef929245f39b294209cbe

add pool_executor in pushmi/examples/pool.h, use it when updating the pushmi benchmark and migrating it to Folly.Benchmark

Summary: The PushmiBenchmark was badly bit-rotted. Update it for the latest pushmi design, migrate it to Folly.Benchmark, and implement it in terms of a new pushmi::pool_executor that is a thin wrapper over a pointer to a folly::CPUThreadPoolExecutor.

Reviewed By: kirkshoop

Differential Revision: D14550589

fbshipit-source-id: d808d6f5795ead421e6ee88439adb9ee652d3146

Summary:
[Folly] Enforce C++14 or later.

Could alternatively do it via C++14-only syntax which would work for all target compilers, but this way the intention is clearest.

Reviewed By: mzlee

Differential Revision: D13649917

fbshipit-source-id: 0783dfd3e471d32626bbd44cc22584d83b5c21d4

Summary:
The intent is to allow heavy users of Function to determine the runtime weight of each of them and evaluate functionally-equivalent options for their code structure (for example: lambda vs function vs `std::bind`) to pick the most space-efficient on their platform.

Limitations
=
If the real function type defines a custom `operator new` that allocates a different amount of memory than `sizeof(...)` suggests it should: that will not be accounted correctly.

We can't look into the real function type at what it itself has allocated. This means that if you capture a unique_ptr to `null` or a unique_ptr to a 4Gb buffer the reported size will be the same.

Reviewed By: ericniebler

Differential Revision: D14512815

fbshipit-source-id: dc636c8bebddabceaeaa8b869bf37c7f0c64c017

Summary: [Folly] `LifoSem::try_wait`, a synonym for `tryWait`.

Reviewed By: magedm

Differential Revision: D14538142

fbshipit-source-id: 5989223a36cddafca108ebdbafc2b17e8dda5964

Summary:
[Folly] Fix semaphore usage in `UnboundedBlockingQueue`.

Ensure that `wait` is paired 1:1 with `post`.

Reviewed By: davidtgoldblatt, magedm

Differential Revision: D14537954

fbshipit-source-id: def54263da1a33c1b3ffa1de237a2b786572759a

Summary: [Folly] Benchmark for `UnboundedBlockingQueue`, starting with measuring contention of `take()`.

Reviewed By: magedm

Differential Revision: D14537953

fbshipit-source-id: ddbba705787b39377f94ad0d63e85038305116cc

Summary:
The AsyncGenerator<T> class allows you to write a coroutine that asynchronously produces a sequence of values of type T.

This has the same executor-affinity behaviour for co_await as for Task<T> except that the executor can change at co_yield points to inherit the executor from the consumer each time a new value is requested.

Reviewed By: ericniebler

Differential Revision: D14446089

fbshipit-source-id: 710ad922918a135e1fe6eef853410c9a77cc2c28

Summary:
This diff expands fbcode_builder so that it can optionally spawn a macos lego job to run a build.

I've pulled in the macOS third party dependencies used by the watchman and eden builds to support this.
Longer term I want to move to a more granular solution for the third party deps.  Medium term we can move the logic for managing these deps to somewhere more central than just the watchman code.

In the linux flavor of fbcode builder, the setup step is responsible for installing system packages, so I've inserted the LFS download of the macOS deps into that stage.

In order for those macOS deps to be picked up without modifying the folly cmake we need to adjust the environment so this diff also inserts that logic at the top of each generated sandcastle step.

A similar technique could potentially be used for windows builds, but note that fbcode_builder makes some assumptions about linux and requires that bash be available.  Cygwin vs. native paths passed through the environment may be a real concern.  That is something for a follow up diff.

Reviewed By: simpkins

Differential Revision: D14514601

fbshipit-source-id: c2882f45aa4b910b5e65ce6b246c750d20ca2948

Summary:
[Folly] Fix up fiber-related guards in futures code. Because of cyclic `#include`s the preprocessor symbol definition must be moved.

Fixes #1061.

Reviewed By: wez, andriigrynenko

Differential Revision: D14555070

fbshipit-source-id: 5e4966fc0f98351924c00a459cc2d8893df4b368

Reviewed By: lewissbaker

Differential Revision: D14554480

fbshipit-source-id: 1aea2bf01d69550d0cdb68fc61d22b2c0e42664e

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

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

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

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

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

Reviewed By: phoad

Differential Revision: D14494202

fbshipit-source-id: c1be1d9b5bdfe07677713ef00401c85270bbe627

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

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

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

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

Summary:
The macOS 10.14 build is failing in homebrew with some compilation errors in the hash/detail files:

* https://github.com/Homebrew/homebrew-core/pull/37954
* https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/39386/version=mojave/testReport/junit/brew-test-bot/mojave/install___build_bottle_folly/
* https://github.com/Homebrew/homebrew-core/pull/35982

~~~
/tmp/folly-20190114-14797-1m0rah5/folly-2019.01.07.00/folly/hash/detail/ChecksumDetail.cpp:181:28:
 error: '__builtin_ia32_pclmulqdq128' needs target feature pclmul
    y0 = _mm_xor_si128(y0, _mm_clmulepi64_si128(x0, multipliers_4, 0x00));
                           ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/__wmmintrin_pclmul.h:54:13: note: expanded from macro '_mm_clmulepi64_si128'
  ((__m128i)__builtin_ia32_pclmulqdq128((__v2di)(__m128i)(__X), \
            ^
~~~

I noticed a comment by passy in https://github.com/facebook/flipper/pull/125 referencing this same error message "needs target feature pclmul", and the comment also said that it "should be easily fixable by ensuring that -mpclmul is added to the CFLAGS". I had trouble identifying the system architecture as he suggested, but figured that we could just check if the compiler supports that flag and add it for those specific source files if so.

This fixes the 10.14 build for me. It would be nice to set up CI to keep this build working, but it's difficult to currently set up CI for 10.14 without your own hardware, since travis and azure pipelines only support up to 10.13.
Pull Request resolved: https://github.com/facebook/folly/pull/1067

Reviewed By: Orvid

Differential Revision: D14500840

Pulled By: yfeldblum

fbshipit-source-id: 939fb6d495b05491af6e95adc16a0d0bbe86829f

Summary:
- Fix a few shellcheck warnings on `docker_build_with_ccache.sh`.
- This will help when new changes are made to this script as
  shellcheck is run internally.
Pull Request resolved: https://github.com/facebook/folly/pull/1054

Reviewed By: yns88

Differential Revision: D14454554

Pulled By: yfeldblum

fbshipit-source-id: f4b692f21d2478f9db06b478ce56c1ba57fa59e0

Summary: This allows us to always use a dummy keep-alive for all awaitables from coro::Task. We also don't need a custom await_transform for coro::Task anymore.

Reviewed By: lewissbaker

Differential Revision: D14491068

fbshipit-source-id: 0e931c2ae9f52da770b08207e551401e4a3778cb

Summary: Title, remove debugging code that does not seem to be needed anymore

Reviewed By: yfeldblum, davidtgoldblatt

Differential Revision: D14267545

fbshipit-source-id: df57e4b85d850e344b12ce1768a1e1a56ae72bce