Summary:
This is part of "the great r-valuification of folly::Future":

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).filter(...)` instead of `f.filter(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329311

fbshipit-source-id: a2640ffe8c70addee9f9ce3614281aa337acaaaf

Summary:
This is part of "the great r-valuification of folly::Future":

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).reduce(...)` instead of `f.reduce(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329242

fbshipit-source-id: 4f192863e69c12484578db6f756de82b97c4427b

Summary:
Update the TDigest interface to accept unsorted or sorted data.
If unsorted, use a custom radix sort explicitly aimed at this use case:
doubles only, assume small data, so we don't use in-place and everything still
fits in cache (1000-10000 items).

Previously D8875766.  This version does not require newer boost versions, and puts
everything in the heap, so there should be no fiber overflows.

Reviewed By: yfeldblum

Differential Revision: D9197722

fbshipit-source-id: 10088cf14d1ff88e1072c00084e09129271e97ec

Summary: [Folly] Cut config-time detection of `cplus_demangle_v3_callback` and the forward declarations and copy-pasting symbols, replacing them with `__has_include(<demangle.h>)`.

Reviewed By: Orvid

Differential Revision: D9287760

fbshipit-source-id: 4464ec22dd6f96cf081cda6051bebe4d41813390

Summary:
Adding an implementation of X509_get0_tbs_sigalg for pre-1.1.0
versions of OpenSSL

Reviewed By: fredemmott

Differential Revision: D9317612

fbshipit-source-id: b7d270a818f802d7df537cdb23e2129dfb184567

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unit()` instead of `f.unit()`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9308405

fbshipit-source-id: 3ae0001deef1aef203454112757f8f64c47831fc

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).filter(...)` instead of `f.filter(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9308741

fbshipit-source-id: 671b1b7a39f16bcc20ad9f584ed0ca8def53d21c

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).ensure(...)` instead of `f.ensure(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9309465

fbshipit-source-id: dd3bcf753aa54d3c6da647b828c35a436abffecc

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).reduce(...)` instead of `f.reduce(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9309840

fbshipit-source-id: 7dbb26dc5e5c7a04720c1fb903e33dfa799e8713

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by some failures around D7840699 since lvalue-qualification hides that operation's move-out semantics - leads to some use of future operations that are really not correct, but are not obviously incorrect.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unwrap(...)` instead of `f.unwrap(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9309748

fbshipit-source-id: eeda770f9e0d3462e1d4680e45d68c8355156b0c

Summary:
Overall plan to modify Future<T>::then to be r-value qualified and use Future<T>::thenTry or Future<T>::thenValue.

The goal is to disambiguate folly::Future and to improve type and lifetime safety of Future and its methods.

Diff to remove the l-value qualified version of folly::Future::then.

Post on the topic of improving safety of Future: https://fb.facebook.com/groups/fbcode/permalink/1726007767436055/

Reviewed By: marshallcline

Differential Revision: D9175988

fbshipit-source-id: 942ae3e1548e8538497eaa0cbde68829c3145d1d

Summary:
Add utility to IOBuf to wrap iovecs and have WriteChainAsyncTransportWrapper use this.

In the future, custom transports could use this method specialized handling of writev without subclassing WriteChainAsyncTransportWrapper.

Reviewed By: yfeldblum

Differential Revision: D9297258

fbshipit-source-id: 9afc17f2ac2c46a49ce384e7c4d8c3a82afa1eec

Summary:
lvalue-qualified then() has been deprecated
lvalue-qualified get() has been deleted
Pull Request resolved: https://github.com/facebook/folly/pull/911

Reviewed By: LeeHowes

Differential Revision: D9310836

Pulled By: yfeldblum

fbshipit-source-id: 662596bf5985f7ceabb2a23725d51f8e05407340

Summary: As per: https://github.com/facebook/folly/commit/ffbc96640b6db68a8e1b020b1048ab45b0699b23#commitcomment-30059248

Reviewed By: yfeldblum

Differential Revision: D9306902

fbshipit-source-id: 79eca471bf911c6791425432f537c6f2e7f99f49

Summary:
In some cases OPENSSL_IS_BORINGSSL can be defined as simple as:

or in copts:

-DOPENSSL_IS_BORINGSSL

this causing folly to fail compilation.
Pull Request resolved: https://github.com/facebook/folly/pull/909

Reviewed By: ngoyal

Differential Revision: D9308739

Pulled By: yfeldblum

fbshipit-source-id: 2ce6170cd97b75ad2322ac57b45824202fe34f21

Summary:
Adds an async Mutex that allows a coroutine to `co_await` acquiring the lock on a mutex.

This mutex is not cancellable and does not support timeouts, but is very efficient
and does not require any per-operation memory allocations (memory for tracking the list of waiting coroutines is borrowed from the awaiting coroutine frame).

The Mutex class provides fair locking by implementing a FIFO queue of waiting coroutines.
ie. coroutines will acquire the lock in the order that they await the lock operation.
This could be relaxed in the future if needed to provide bounded wait-times but not necessarily FIFO order.

Example usage:
```c++
template<typename T>
class ConcurrentStack
{
  folly::coro::Mutex mutex_;
  std::vector<T> values_;
public:
  coro::Task<void> pushAsync(T value)
  {
    auto lock = co_await mutex_.scopedLockAsync();
    values_.push_back(value);
  }

  coro::Task<Optional<T>> tryPopAsync()
  {
    auto lock = co_await mutex_.scopedLockAsync();
    if (values_.empty()) co_return Optional<T>{};
    T result = values_.back();
    values_.pop_back();
    co_return result;
  }
};
```

Reviewed By: andriigrynenko

Differential Revision: D9209637

fbshipit-source-id: 4b81c8f33b9fc39781f4237d1821b0e0b2e4f3c5

Summary: Pull Request resolved: https://github.com/facebook/folly/pull/910

Reviewed By: simpkins

Differential Revision: D9300288

Pulled By: yfeldblum

fbshipit-source-id: 5724bcc2e9c6602a0e99c436b62893926281e673

Summary:
Adds a fundamental thread-synchronisation primitive for coroutines
that allows one or more coroutines to suspend execution until some thread
signals them.

This differs from the folly::fibers::Baton implementation in that it
does not expose a blocking wait API, only an asynchronous wait API that
must be waited-on from within a coroutine. This implementation also
permits multiple coroutines concurrently waiting on the baton.

Example usage:
```c++
folly::coro::Baton baton;
std::string sharedValue;

folly::coro::Task<void> consumer()
{
  // Wait until the baton is posted.
  co_await baton.waitAsync();

  // Now safe to read shared state.
  std::cout << sharedValue << std::cout;
}

void producer()
{
  // Write to shared state
  sharedValue = "some result";

  // Publish the value by 'posting' the baton.
  // This will resume the consumer if it was currently suspended.
  baton.post();
}
```

Reviewed By: andriigrynenko

Differential Revision: D9208955

fbshipit-source-id: 07aa372b4c6b90dc0565763add716e591d312c65

Summary:
We try to detect if you're building for a darwin version where clock_gettime doesn't have a library definition and provide our own if that's the case. However, if you build for an earlier darwin verion but then run on a newer darwin version where clock_gettime does have a definition our symbol still overrides that one, when I think it shouldn't (I'd rather use the library definition whenever possible). This is one of the exact situations why weak linkage exists (I guess at least on darwin since that's the only place I have knowledge), so let's use it here: provide our own definition if a library one doesn't exist, otherwise the strong library definition will override ours.

This creates the following issue now: previous to this diff you would have a unified API (though divergent from the system one on darwin) across all versions of darwin when linking in this library. Now when running on a newer version of darwin the semantics of each clock type may change (in fact I know CLOCK_MONOTONIC diverges). Look for a follow up diff to try and patch up divergence.

Reviewed By: mzlee, Orvid

Differential Revision: D8781475

fbshipit-source-id: e80e9d309115b64563511935ef074c4f46da025b

Summary: Successfully built on Fedora, added a comment that it will work on Fedora up to 28

Reviewed By: yfeldblum

Differential Revision: D9147146

fbshipit-source-id: a768eee4becadcb017547d96207d63d43ec2be57

Summary:
[Folly] Replace `FOLLY_HAVE_FEATURES_H` with `__has_include`.

Now that folly only targets which support `__has_include`.

Reviewed By: simpkins

Differential Revision: D9281991

fbshipit-source-id: 2e263681df5a980220fc133e8ac0495f229f6084

Summary:
[Folly] Replace `FOLLY_HAVE_MALLOC_H` with `__has_include`.

Now that folly only targets which support `__has_include`.

Reviewed By: Orvid

Differential Revision: D9281875

fbshipit-source-id: eb895f3e034e4a4d3c9eb34fb73d47893e59f5ef

Summary:
[Folly] Replace `FOLLY_HAVE_LIBDWARF_DWARF_H` with `__has_include`.

Now that folly only targets which support `__has_include`.

Reviewed By: Orvid

Differential Revision: D9281453

fbshipit-source-id: f416a6e4eb25ec31f86c705b7e9aafb1064e876a

Summary:
[Folly] Replace `FOLLY_HAVE_BITS_CXXCONFIG_H` with `__has_include`.

Now that folly only targets which support `__has_include`.

Reviewed By: Orvid

Differential Revision: D9280942

fbshipit-source-id: cd843b4e903b2c96d3a40611f2274572b8b0600a

Summary:
[Folly] Replace `FOLLY_HAVE_LINUX_MEMBARRIER_H` with `__has_include`.

Now that folly only targets which support `__has_include`.

Reviewed By: Orvid

Differential Revision: D9279852

fbshipit-source-id: 94c446a2d6e2662d32a7899ab470679da6da8e0e

Summary:
This fixes various include and dependency issues found when building
`folly/compression/test/facebook:compression_fuzz_test.so` with modules.

Reviewed By: yfeldblum

Differential Revision: D9271280

fbshipit-source-id: e0ae46c2a6d95c8f4d0a66e3dc20e1d045ffc6a4

Summary: This reverts my previous change "RequestContext: replace F14FastMap by std::unordred_map"

Reviewed By: ot

Differential Revision: D9280469

fbshipit-source-id: ad3f4d5f520e88ab0e0fab0506d87bab2cd10d41

Summary:
[Folly] Epochs for `BufferedRandomDevice`.

To maintain the security property that the thread-local object is reset after fork in the child process, but in an async-signal-safe way.

This approach has the downside that it makes the fast path larger by 3 instruction (`mov`, `cmp`, `jne`).

Reviewed By: djwatson, ot

Differential Revision: D9256536

fbshipit-source-id: dc34e1aeb75e1009610d47fe4ef7030a4a0e2a90

Summary:
The following code won't compile with g++ 8.2 when `-Wall -Werror` is turned on (`-Werror=class-memaccess` implied):

    std::memcpy(dst, src, n * sizeof(Value))

where in `VectorContainerPolicy`'s case, `Value` is typically an `std::pair`, which  indeed has no trivial copy-assignment.
Pull Request resolved: https://github.com/facebook/folly/pull/907

Reviewed By: yfeldblum

Differential Revision: D9244951

Pulled By: Orvid

fbshipit-source-id: 26787d43dab7d4212c5975a509dfd8703b0a157c

Summary:
Overall plan to modify Future<T>::then to be r-value qualified and use Future<T>::thenTry or Future<T>::thenValue.

The goal is to disambiguate folly::Future and to improve type and lifetime safety of Future and its methods.

Reviewed By: yfeldblum

Differential Revision: D9273440

fbshipit-source-id: f1e1b91fd8fe02020a5919b9193644e256413982

Summary:
[Folly] Cut `FOLLY_HAS_INCLUDE` now that all supported platforms have it.

MSVC2015 and gcc4.9.1 don't support it, but folly no longer targets them.

Reviewed By: simpkins, Orvid

Differential Revision: D9262258

fbshipit-source-id: e518492acd7c11374ab971b26adb642bce7b19c3

Summary: Fix various dependency issues in folly for modular build.

Reviewed By: yfeldblum

Differential Revision: D9246772

fbshipit-source-id: 32afa48db3222b906077376c54e1301c8366d97d

Summary: Move Password in file from wangle to folly

Reviewed By: ngoyal, yfeldblum

Differential Revision: D9192652

fbshipit-source-id: b883ddaf2d815b37677d9c5e924b3dd06aa0ec6b

Summary:
Move the definition of `HAZPTR_DEBUG` from code to the target to fix modular
build. This is needed because `HAZPTR_DEBUG` is effectively a configuration
macro affecting the API.

Reviewed By: magedm

Differential Revision: D9256127

fbshipit-source-id: 44deb0e915373ea88206098544b03fa335b31a22

Summary:
F14 varies its inline code according to the flags passed to the
compiler. This can cause problems if libraries override compilation flags
on their own, since it won't be safe to exchange F14 instances between
compilation domains.  This diff introduces a template specialization
that varies according to the intrinsics mode and that has only a single
definition (in F14Table.cpp).  The member is called on a couple of cold
paths (exception handling for copy construction and rehash).  This makes
it very likely that a compilation unit that uses F14 and is compiled
with different compiler flags than F14Table.cpp will get a linker error.

Reviewed By: yfeldblum

Differential Revision: D9200315

fbshipit-source-id: 9cbca18eef0ddd6efcf6d9d6057eda2400f8653c

Summary:
As indicated at https://github.com/krb5/krb5/blob/master/src/include/krb5.h,
this header is deprecated, so update to use the new location (and fix lint).

Reviewed By: luciang

Differential Revision: D9259770

fbshipit-source-id: 6832206b8c890184f5d3369b0305048ae9c377d9

Summary:
Make the file name consistent with its class name
Add benchmark code
Attach performance data

Reviewed By: magedm

Differential Revision: D9250954

fbshipit-source-id: b9f9b90cb83ca319d91fe65667d0072511be5e26

Summary:
Update the CMake build files to install a libfolly.pc file so downstream
projects can use pkg-config to more easily depend on folly.

Reviewed By: yfeldblum

Differential Revision: D9213429

fbshipit-source-id: 849c0fce01d4903d3f8a7b6d196037bf950e5921

Summary:
folly, and therefore most of our other open source projects, no longer support
gcc-4.9.  Drop Ubuntu 14.04 and Debian 8.6 from our CI platforms list, since
the these images only support gcc 4.9.

We should ideally add support for Ubuntu 18.04 soon, but I'll leave that for a
later diff.  Removing the older platforms is somewhat higher priority for now
to get our Travis CI builds green again.

Reviewed By: snarkmaster

Differential Revision: D9258797

fbshipit-source-id: 3cab47a6c51b2dbe63214034240f844c85963c3d

Summary:
Fork test tries to test that we don't reuse the SecureRandom buffer on fork, but it only tests one byte.

This gives us probability one in 256*256 (or something like that) that we spuriously fail.

Check the whole buffer instead before failing.

Reviewed By: fredemmott

Differential Revision: D9242788

fbshipit-source-id: b9fb809518797c439d7fe16084a04f9964a1f597