Summary:
[Folly] Apply `clang-format` to non-compliant locations (partial).

(Note: this ignores all push blocking failures!)

Reviewed By: igorsugak

Differential Revision: D13858983

fbshipit-source-id: 668c3ee209456befd3c03d85945321143da2b00a

Summary: They aren't needed

Reviewed By: yfeldblum

Differential Revision: D13855963

fbshipit-source-id: c822a4b806350ef178906401b2239a865fd77119

Summary: It was broken due to oddities with how MSVC handles expanding `##__VA_ARGS__` within the parameters to macros. Rather than deal with the pre-processor, just return the check to how it was and use `EXPECT_TRUE(false)` to achieve the same effect.

Reviewed By: yfeldblum

Differential Revision: D13850142

fbshipit-source-id: 887b39fb3c6072219c3f4748599bc7b707efbf25

Summary: [Folly] SemiFuture::deferError and Future::thenError overloads taking exception-type-carrying tag to distinguish the exception type. Solves the case where `.deferError` or `.thenError` is called on an object with a dependent type, where passing the exception type otherwise requires the `template` keyword.

Reviewed By: LeeHowes

Differential Revision: D13855497

fbshipit-source-id: 74200853043e3fdbc08419b33b959f3519d704ef

Summary: [Folly] A generic tag type for all your generic tag-related needs. With naming following the pattern of `std::in_place_t` and `std::in_place`.

Reviewed By: kirkshoop

Differential Revision: D13855499

fbshipit-source-id: 50b7e41fbbb843c6c9b766f8b66484d6aa23c167

Summary:
`value_before` looks like a pre-C++11 artifact, replace with `std::prev`.

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D13852269

fbshipit-source-id: c2e4e8178754a694650f53633f099d05da4127d7

Summary:
Upgrade locks allow access concurrently with readers, so mutating the state under an upgrade lock can potentially introduce a race unless proven otherwise.
The main goal of this diff is to make the accessors to `Synchronized` state `const` under upgrade lock, as it happens under a shared lock. To achieve so, the diff changes the mechanism by which `const` is added: instead of unconditionally closing a `const Synchronized` in the `LockedPtr`, it captures the same constness as the `Synchronized`, and then the `const` decision is done at access time.

This enables having an extra method `asNonConstUnsafe()` that gives non-const access when needed without requiring a `const_cast`. This is now provided for shared locks as well.

Reviewed By: yfeldblum, aary, davidtgoldblatt

Differential Revision: D13817413

fbshipit-source-id: 8c315a925db9b1da8821984c59e55e90571b194e

Summary: [Folly] Apply `clang-format` to `folly/FBString.h`. A previous change was not properly formatted.

Reviewed By: ot

Differential Revision: D13831558

fbshipit-source-id: 318404a3a14d6969cc2aa9601e72fae6ad6cfac2

Summary: Remove duplicate code from Future::onError and have it call Future::thenError.

Reviewed By: yfeldblum

Differential Revision: D13823960

fbshipit-source-id: d2e48e4e65e30c80adbbd70ff314e1a418b7c1e2

Summary: As per Yedidya Feldblum comment on my previous diff, we need a duration cast in here.

Reviewed By: yfeldblum

Differential Revision: D13833032

fbshipit-source-id: 8819694875bd3a7e4f54102d8ac77490f8287fbb

Summary:
* Split thenError into future-returning and not-future-returning forms as we cannot rely on onError for this.
 * Move core functionality from onError into thenError to avoid thenError depending on onError.
 * Makes thenError's continuation consistent with other forms such that the parameter is passed by r-value, hence an l-value reference is no longer valid.

Reviewed By: yfeldblum

Differential Revision: D13820171

fbshipit-source-id: cf42a7d1c0759c5cfbb03f8e66a6d6988f7e10c7

Summary: This makes it easier to debug and diagnose build problems

Reviewed By: simpkins

Differential Revision: D13831342

fbshipit-source-id: 3921a05715fb00264b2e1a6e134686d68aea804d

Summary: [Folly] Cut various sites supporting MSVC <= 2015, which is insufficiently compatible.

Reviewed By: Orvid

Differential Revision: D13747631

fbshipit-source-id: 3d63d3a57258b5695b1236a81f3ddfe2f4af9cb4

Summary:
Title. This gets rid of benign TSAN lock order inversion detections.

(Note: this ignores all push blocking failures!)

Reviewed By: spalamarchuk

Differential Revision: D13820662

fbshipit-source-id: f092a988faa2cc897a1d046385e4bc4fd0422c7c

Summary: Add an HHWheelTimer-fwd.h header

Reviewed By: djwatson

Differential Revision: D13780411

fbshipit-source-id: 795352c3eeed38cd52a270ebdf5dd734604415fa

Summary:
This should allow more direct testing of changes without waiting for things to land on github first.

As part of this, to avoid a conflict between the deps that bistro downloads and those used by
the rest of the fbcode builder CI, I've updated the version of gtest used by bistro.

Reviewed By: zertosh

Differential Revision: D13802637

fbshipit-source-id: fd71bfabd2a85f4f63c21b44a1e868f2d293180a

Summary: This is useful to avoid extra allocations when integrating with code that doesn't use folly::futures.

Reviewed By: yfeldblum

Differential Revision: D13812866

fbshipit-source-id: aa76b8cda43d1a781e058f6edbe2ecb8100268de

Summary: The headers are installed, but we weren't compiling the implementation.

Reviewed By: simpkins

Differential Revision: D13778568

fbshipit-source-id: 4d297b732d1e70bbd69100f13eb68f9477d7f014

Summary: This helps avoid executor re-schedule when Future is ready.

Reviewed By: yfeldblum

Differential Revision: D13805939

fbshipit-source-id: f553c7a581882a7b53b004fd6bbb5087ea5787f8

Summary: Currently, `runOnDestruction` aims to be thread-safe; new callbacks are added to the `onDestructionCallbacks_` list while the associated mutex is held. However, the caller may own the `LoopCallback` and wish to destroy/cancel it before the `EventBase` destructor runs, and this callback cancellation is not thread-safe, since unlinking does not happen under the lock protecting `onDestructionCallbacks_`. The primary motivation of this diff is to make on-destruction callback cancellation thread-safe; in particular, it is safe to cancel an on-destruction callback concurrently with `~EventBase()`.

Reviewed By: spalamarchuk

Differential Revision: D13440552

fbshipit-source-id: 65cee1e361d37647920baaad4490dd26b791315d

Summary: Apply timed reclamation to tagged and untagged lists to avoid accumulating a large amount of unreclaimed memory in use cases with large protectable structures.

Reviewed By: davidtgoldblatt

Differential Revision: D13779937

fbshipit-source-id: e2e14ac5f18c1ee30808116cbc29d21895d9fb1c

Reviewed By: yfeldblum

Differential Revision: D13800383

fbshipit-source-id: 61b988182cb8da6f084b62a0879f0ca917f8ad34

Summary:
Current implementation will loop over bitmap to figure out next tick to schedule. This consumes visible amount of CPU (10% in fibers benchmark, ~4% of Thrift noop load test).

However, this looping is unnecessary, because we already have all information available - what is the earliest pre-existing timeout (expireTick_) and the new one. So we can decide what tick to schedule for by just simple conditional statement.

Reviewed By: vitaut

Differential Revision: D13709523

fbshipit-source-id: b0e3e6301cc2e759b4e8901ba5ff009587516cf5

Summary: Got outdated in D3143931.

Reviewed By: yfeldblum

Differential Revision: D13494612

fbshipit-source-id: e24bfea36896ec04b15fa443348e00f50f75940d

Summary: setCallback_ is an internal API that doesn't provide a guarantee that when the callback is run the Try will be stored inside of the original future. Thus the Try should be moved by the callback instead.

Reviewed By: LeeHowes

Differential Revision: D13793991

fbshipit-source-id: 1e8c4e423b8e1786099cae84bd99ac350c32d937

Summary: make an adapter executor that forwards add to addWithPriority of the underlying executor

Reviewed By: andriigrynenko

Differential Revision: D13788642

fbshipit-source-id: 5b4af43f4a3a3931817a2425890558f811152225

Summary: [Folly] Cut `pushmi` example which uses non-yet-`std` names.

Reviewed By: kirkshoop

Differential Revision: D13777367

fbshipit-source-id: 7ae846e74b622fb0f434220961d35bb243be6868

Summary:
Most of the tests that use this macro, use it to ensure proper behavior of time-related logic (i.e. timeout didn't fire too early/late). Skipping them, simply masks a failure. The underlying utility already takes care of lags due to scheduling, so whenever this check fails - means we have a bug.

In particular, we have 3 tests for HHWheelTimer that are always skipped, because their tolerance is below the expected lag of HHWheelTimer (it always rounds up, so we should expect +1ms always).

Reviewed By: vitaut

Differential Revision: D13746558

fbshipit-source-id: 78f954f52414e640af92e5bb50790135cdd89a92

Summary: was reading coro example and i think a line is missing

Reviewed By: andriigrynenko

Differential Revision: D13788989

fbshipit-source-id: ceb024a36ddd89369ee25f6632fce8d339c489cb

Summary: [Folly] Tweak deletion of `fbstring::operator=` taking convertible-to `char`.

Reviewed By: Orvid

Differential Revision: D13747744

fbshipit-source-id: f254f13a15cb0e72120d1d02f4c8893a788e429a

Summary:
Make sure SCOPE_FAIL works with std::rethrow_exception().

When compiled with older versions of gcc this code would fail due to a gcc
bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258
The gcc bug was fixed in 4.9.4, 5.3, and the 6.0 branch.

Reviewed By: meyering

Differential Revision: D3280778

fbshipit-source-id: 8fe1a9c1dc3ada61c8ebd7318538ae959b29a6b1

Summary:
The other tests are either simple API tests for single-threaded cases, or a
benchmark.

Reviewed By: djwatson

Differential Revision: D13678336

fbshipit-source-id: 5aba91879d756097f42d245b5d318ad7c945dfeb

Summary:
Until C++17 constructor type deduction becomes a thing, we can use this
instead to mimic unique_lock construction without having to specify the type
of the mutex explicitly.

```
auto lck = folly::make_unique_lock(mutex);

// as opposed to

auto lck = std::unique_lock<MutexType>{mutex};
```

Reviewed By: davidtgoldblatt

Differential Revision: D10386999

fbshipit-source-id: 0780a6d1769597a3888305248bcdf93a84c9f9ee

Summary: See F14.md changes.

Reviewed By: nbronson

Differential Revision: D13722323

fbshipit-source-id: 70c68442cad56efc84bb29f0b694a7b71f837cbd

Summary:
This adds support for the Lockable concept for DistributedMutex through a
unique_lock specialization.  There is also a corresponding lock_guard
specialization.  This should cover 95% of usecases very well.  The other 5%
should probably consider using std::unique_lock, std::lock_guard or
folly::Synchronized

Note that std::unique_lock and std::lock_guard can be specialized.  The
standard does not explicitly prevent specializations for these classes as long
as the specializations are dependent on user-defined classes.  This makes it
ok for us to specialize these two interfaces for our folly mutexes.  See the
quoted paragraph below

Section §[namespace.std]

> A program may add a template specialization for any standard library
> template to namespace std only if the declaration depends on a user-defined
> type and the specialization meets the standard library requirements for the
> original template and is not explicitly prohibited.

The generic lockable wrappers that implement the std::unique_lock and
std::lock_guard interfaces are present in
folly/synchronization/detail/ProxyLockable.h.  The specializations of
std::unique_lock and std::lock_guard in namespace std use these
implementations.  This allows us to stick with a simple specialization for our
mutex, which is well-defined per the paragraph above

Reviewed By: djwatson

Differential Revision: D10377227

fbshipit-source-id: 9f2c50ff5732714c83a79752f58c792e6b2a5e88

Summary: The size of the vector is essentially 4, there's no point of allocating it on heap. This improves locality and avoids unnecessary indirection.

Reviewed By: jmswen

Differential Revision: D13709524

fbshipit-source-id: 76c80b835a73ec8f7f5096ae927292571d137596

Summary:
Add test to ThreadPoolTest that LifoSemMPMCQueue::add does not throw when queue is not full.

The test fails before changing LifoSemMPMCQueue::add to use MPMCQueue::writeIfNotFull instead of MPMCQueue::write,and passes after the change.

Reviewed By: djwatson

Differential Revision: D13722155

fbshipit-source-id: 09e296f18eba5c3a78734284b5e409cf006951cc

Summary:
This change ensures that LifoSemMPMCQueue and PriorityLifoSemMPMCQueue do not throw unless the queue is full.

Before this change it was possible for an add operation to throw even when the queue is not full, if a consumer operation is delayed while in progress.

Example:
Queue of size N.
T1: Producer completes N add operations.
T2: Consumer starts a take operation and gets delayed.
T3: Consumer completes N-1 take operations.
T1: Tries an add operation. If using MPMCQueue::write (which returns false) throws even though the queue is not full (has N-1 empty slots). If using MPMCQueue::writeIfNotFull() returns true after waiting for T2's take to complete.

This is somewhat similar to BugD3527722.

Reviewed By: djwatson

Differential Revision: D13701978

fbshipit-source-id: a799353c41d0dc6e673b5fe0ad2a64fd5440fbe8

Summary:
- Use `std::mt19937` instead of `boost::random::mt19937`.
- Use `std::uniform_int_distribution` instead of `boost::uniform_int`.
Pull Request resolved: https://github.com/facebook/folly/pull/1000

Reviewed By: aary

Differential Revision: D13729752

Pulled By: yfeldblum

fbshipit-source-id: 26828c157c458e56ce225af25e2a96890f0633ab

Summary: [Folly] `SingletonRelaxedCountable`, a convenience API around `SingletonRelaxedCounter` for counting instances of a type.

Reviewed By: ovoietsa

Differential Revision: D13686867

fbshipit-source-id: b2f7673e7e88c473337f66901c3e787d35eca6c6