Summary:
This switches the output queue from `Output` to `Expected<Output, std::exception_wrapper>`, allowing exceptions to be produced by the predicate. Prior to this change, any exceptions would FATAL, taking down the whole process.

Benchmarks appear unaffected. Memory use will be very similar: Small objects are already padded out to a cache line, so the increase in size will often be zero.

Reviewed By: luciang

Differential Revision: D14625210

fbshipit-source-id: 9bfa1197b7d2285bbc7e42e829beeb3525b3bd44

Summary: Adding note and disabled test for now, will come back to fixing or killing this later.

Reviewed By: yfeldblum

Differential Revision: D14625209

fbshipit-source-id: 6e4f523c02e28fa6080da16485cba68ee78ffc80

Differential Revision:
D13966702

Original commit changeset: 415622dc347d

fbshipit-source-id: 11ff9cac08174cfaefe20e7e4c5e08dc005aaa39

Summary:
This causes problems with the cmake build because boost
triggers this warning, and we're promoting this to an error.

It is possible to use `-isystem` to tell the compiler that the
the boost headers are system headers, but introducing that for
boost headers is a mess.

We can safely live without this warning in the open source build
as our buck based builds have this enabled correctly.

Reviewed By: yfeldblum

Differential Revision: D14631786

fbshipit-source-id: cf30d0921ce592f410c2ad4bfddba1bddef01ed7

Summary: HHWheelTimerBase: use different DEFAULT_TICK_INTERVAL values for milliseconds and microseconds

Reviewed By: djwatson

Differential Revision: D14608368

fbshipit-source-id: 81ca30dead56e0ec954fce05c9f920e15dc20405

Summary:
- Clang 8 introduces a new compiler option which is turned on by
  default: `-Wdefaulted-function-deleted`.
- This flags some code which has special member functions which we
  declare as defaulted, but are implicitly deleted. As such, it is a bit
  misleading to mark them as defaulted. So, mark them as deleted. We
  could also remove them and they would be implicitly deleted, but then
  the internal linter would not like that we define a user defined type
  but are not explicit about deleting or defaulting all special member
  functions.

Note:
- This fixes some Clang 8 compilation issues, but
  https://github.com/facebook/folly/issues/1081 contains details about the
  remaining issues.
Pull Request resolved: https://github.com/facebook/folly/pull/1082

Reviewed By: Orvid

Differential Revision: D14613574

Pulled By: yfeldblum

fbshipit-source-id: 8011b3bc456bf92bbaf374c045fffb130e26d38b

Summary: This is a largely automated codemod that shifts `folly::AsyncServerSocket::AcceptCallback::connectionAccepted` to taking a `NetworkSocket` rather than a file descriptor. This needs to be done as a single atomic change to avoid breaking things.

Reviewed By: yfeldblum

Differential Revision: D13966702

fbshipit-source-id: 415622dc347de53368c404dfbe9a2deae5b75e18

Summary:
- Replace a check for deduction guide support to use a feature test macro
  for deduction guides rather than a check using `__cplusplus` directive.
- The existing check using the `__cplusplus` directive is not correct
  for GCC 5.1. With GCC 5.1, `__cplusplus > 201402L` will be true, but the check
  for `#if __cpp_deduction_guides >= 201703` will be false. So, it is
  not valid to just rely on the `__cplusplus` directive to infer
  deduction guide support.
- We extend the check to use the feature test macro except in the case
  of MSVC, which we infer the feature is supported. MSVC does not define
  feature test macros, despite having implemented the feature.
Pull Request resolved: https://github.com/facebook/folly/pull/1065

Reviewed By: aary

Differential Revision: D14518809

Pulled By: yfeldblum

fbshipit-source-id: a976ae527ef986ae6d3fc52c316af9bf8e209767

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