Summary:
For use in tests where the executor has a nontrivial lifetime but any
queued jobs should be completed, have ManualExecutor drain itself
before it's destroyed.

Reviewed By: yfeldblum

Differential Revision: D8845457

fbshipit-source-id: 7c2aa65aa27a7850ff73a93cfbe34c2248b62d26

Summary:
Change the write acquire interface to only acquire write locks on non-const
`Synchronized` instances.  This reflects the intention of mutation associated
with a write lock.

Reviewed By: yfeldblum

Differential Revision: D8851208

fbshipit-source-id: 5be9d2e4a38d25632430a9b6c981b6e7f8412daa

Summary: Fix broken opt build due to "error: unused variable 'rv'"

Reviewed By: yfeldblum

Differential Revision: D8883701

fbshipit-source-id: 2a832cfea0bd9cbca63a8d5c2c8d7127593728af

Summary: Users acquiring upgrade locks should only be allowed to lock the synchronized object when it is non-const.  Because an upgrade locks are permitted to transition to write locks when mutation is required.  At which point non-const access is often required on the Synchronized object.

Reviewed By: yfeldblum

Differential Revision: D8654360

fbshipit-source-id: c2a6574bd880db0d8e4c90166e288f5b83542ad6

Summary:
F14 currently has numerous places where folly::assume is used to
help optimization on GCC < 6.  These are all things the optimizer should
be able to deduce itself, so it would be nice to eventually remove them.
This diff marks them with TODO(T31574848), as well as removing two
occurrences in F14Table that duplicated an assume in F14Policy.

Reviewed By: yfeldblum

Differential Revision: D8849832

fbshipit-source-id: e88143b4d29f1a633b51467206c6fb6afd1cd296

Summary: Remove the ' ' prior to : in folly::json's pretty output - this improves consistency with other JSON formatters.

Reviewed By: yfeldblum, luciang

Differential Revision: D8843977

fbshipit-source-id: 1d5c84d7d3806ad8752b619ffe23101f7f103683

Summary:
- Add cleanup of remaining items, if any, at destruction.
- Add test.

Reviewed By: davidtgoldblatt

Differential Revision: D8860966

fbshipit-source-id: e3ab2e6ff31e08d91aa20c8c058471823c722a38

Summary: Add test to detect no reclamation (without calling hazptr_cleanup). The test retires a number of objects that would trigger bulk reclamation. One or more objects are expected be reclaimed. The number of retired objects must be greater than or equal to hazptr_domain::kThreshold to expect reclamation to happen.

Reviewed By: yfeldblum

Differential Revision: D8849957

fbshipit-source-id: ef590af21a55348ed0ed72be3637853eceb21cbc

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

* This is something we should do for safety in general.
* Using lvalue-qualified `Future::get(...)` has caused 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.
* Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get()`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
* Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.
* Note: `get(...)` refers to `get()` and `get(Duration)`.

Reviewed By: yfeldblum

Differential Revision: D8710296

fbshipit-source-id: ae201af1928eb2f6a2897c9b7db884393b36b910

Summary: The most recent change had a bug that prevents all calls to hazptr_priv::push_all_to_domain from trying reclamation, instead of preventing that only when called from the destructor of hazptr_priv and during reclamation.

Reviewed By: davidtgoldblatt

Differential Revision: D8849738

fbshipit-source-id: 15a27e8d4a88288179609e8cf179bc8c10c96b90

Summary:
This diff performs several micro-optimizations that improve
the lifecycle of a single-element F14FastMap or F14FastSet by about 10%
(in a single-threaded microbenchmark).  Lifecycle here means construction,
insertion of one entry, and then destruction, so it includes one malloc
and one free.

Reviewed By: yfeldblum

Differential Revision: D8771446

fbshipit-source-id: 95d59f32de5a450b16ecdcb0e39b7f566ce797da

Summary:
This adds `XCHECK()` and `XDCHECK()` macros to the folly logging library.
These are similar to glog's `CHECK()` and `DCHECK()` macros, and should make
it easier for users to convert from glog to folly logging.

`XCHECK(condition)` is basically an alias for `XLOG_IF(FATAL, condition)`

`XDCHECK(condition)` is like `XCHECK(condition)` in non-debug builds, but is
compiled out entirely in debug builds.  Note that this is *not* like
`XLOG_IF(DFATAL, condition)`, which still evaluates the condition but avoids
crashing (logging the message only) in release builds.

Reviewed By: mnv104

Differential Revision: D8817270

fbshipit-source-id: 86c4575e11af37219b30eda4e7e30273e1e32ab1

Summary:
Previously `XLOG_IF(FATAL, condition)` always crashed regardless of the
condition check.  When `XLOG_IF()` was added it did not update the checks used
to mark the statement as `[noreturn]` based on the log level.  As a result
`XLOG_IF(FATAL, ...)` always used the `[noreturn]` APIs, even though this code
can return if the condition is not true.

This splits the `XLOG()` and `XLOG_IF()` implementations so that `XLOG(FATAL)`
can still be marked as `noreturn` but `XLOG_IF(FATAL, ...)` is no `noreturn`.

Reviewed By: yfeldblum, mnv104

Differential Revision: D8817269

fbshipit-source-id: 47a493eaaac69c563cff07da0888dd423f7dc07d

Summary:
Run clang-format across folly/executors/.

```
find . \( -iname '*.cpp' -o -iname '*.h' \) -exec clang-format -i {} \;
```

Reviewed By: yfeldblum

Differential Revision: D8843064

fbshipit-source-id: 0a3c82083eebf2c684a4ab2e12067f0f742bf1d4

Summary:
C++17 actually removes this overload of `std::addressof` to avoid taking the address of constants. It's not clear to me that the second test here is actually adding much value here.

See (2) at: https://en.cppreference.com/w/cpp/memory/addressof

Reviewed By: yfeldblum, elsteveogrande

Differential Revision: D8775544

fbshipit-source-id: a42209484574509f4d032ebbdf05430f0ed372c4

Summary:
This changes `IntervalRateLimiter` to allow it to be `constexpr`-constructible.

We now always initialize the `timestamp_` field to 0.  The very first call to
`check()` will now always call `checkSlow()` which will then initialize
`timestamp_` properly.

This also removes the pure virtual `RateLimiter` interface class.  At the
moment `IntervalRateLimiter` is the only implementation, and all call sites
use this class directly.  We can always add the `RateLimiter` interface back
in the future if we need it later.

Reviewed By: yfeldblum

Differential Revision: D8798167

fbshipit-source-id: 80885a16506a8daa67653bd0a92accae7a973289

Summary: Reformat fatal_test.py with black (https://github.com/ambv/black)

Reviewed By: mnv104

Differential Revision: D8817268

fbshipit-source-id: b642496ac61e3b2120b76d9b234c29bf51603651

Summary:
Update the static local variable names used in `XLOG_IMPL()` and
`XLOG_IS_ON_IMPL()` to match the naming style used in D8218663.

The current version of clang-format also appears to be able to format
`XLOG_IMPL()` correctly now, so remove the comments disabling it around this
macro body.

Reviewed By: yfeldblum

Differential Revision: D8816625

fbshipit-source-id: 155b759953de5d5db0b350f27870edf9f5516914

Summary:
This adds several macros for explicitly rate-limited log messages.

- `XLOG_EVERY_N()` logs only 1 of every N times it is called.
  This is similar to glog's `LOG_EVERY_N()` and `VLOG_EVERY_N()` macros.

- `XLOG_EVERY_MS()` logs only once per specified time interval.
  This is similar to the `LOG_EVERY_MS()` and `LOG_EVERY_MS_ATOMIC()` macros
  that Facebook has defined internally on top of glog.

- `XLOG_N_PER_MS()` logs the first N messages per specified time interval.

These should make it easier for Facebook programs to migrate from glog to
xlog.

Reviewed By: yfeldblum

Differential Revision: D8218663

fbshipit-source-id: a1e71265ace41fea95e5dbb79bc4381962b11297

Summary:
Delayed hazptr destruction is causing destruction ordering issues.

P59812860$445

buck test //titan/cachius/test:CachiusServiceHandlerTest

Reviewed By: phil-lopreiato

Differential Revision: D8825716

fbshipit-source-id: 808341489fd80b8edb63eb7c12377a8ffadfd1eb

Summary:
This extends fibers::Baton to support any awaiter (not just folly::Fiber) which makes it possible to integrate it with coroutines.
This will make it easy to integrate existing synchronization primitives that use fibers::Baton with coroutines.

Reviewed By: lewissbaker

Differential Revision: D8580775

fbshipit-source-id: 8f8593793d3012e0470b8f9b3bcf2713145d3573

Summary: Prevent destructor of hazptr_priv which is a SingltonThreadLocal from making call to get a reference to the singlton. This may be a problem on some platforms.

Reviewed By: djwatson

Differential Revision: D8711918

fbshipit-source-id: fb319f640cff74e46ce27ab28ae5fbf93961b262

Summary:
Specializing folly::IsAvalanchingHasher can be bulky and
mistake-prone, such as constructing a new hash functor by subclassing.
For example, folly::IsAvalanchingHasher<folly::transparent<H>, K>
was incorrectly false even when H is avalanching.  This diff adds the
ability to use a member type is_avalanching to accomplish the same
effect, and also fixes the computation of folly::IsAvalanchingHasher
for folly::transparent.

Reviewed By: yfeldblum

Differential Revision: D8772423

fbshipit-source-id: 49e4e33b2981efd8c302d9a217dc9df0dcb290cc

Summary: The `Emptiness_T` test already tests the emptiness of a default-constructed Function as well as one that was assigned an empty Function. This diff adds a test for a Function that was move-constructed from an empty Function.

Reviewed By: shixiao

Differential Revision: D8818468

fbshipit-source-id: 3f0e04b9f0f44df2de45fc972a2d26e12adc7362

Summary: F14 code inside namespace folly doesn't need folly::

Reviewed By: yfeldblum

Differential Revision: D8772565

fbshipit-source-id: 720fa683b7ec9be9a096559191240ef7e672fe3e

Summary: [Folly] Reorder `#include`s in `folly/io/async/HHWheelTimer.cpp`.

Reviewed By: djwatson

Differential Revision: D8806020

fbshipit-source-id: 43496acdaac3b8a79169b00913881d17d160906c

Fix requestcontext destruction before globals are destroyed.
Bad stacktrace P59804825

Reviewed By: yfeldblum

Differential Revision: D8797823

fbshipit-source-id: a9cbff159e5a0ab2577cb7412817be5d554aa32f

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

* This is something we should do for safety in general.
* Context: `Future::get(...)` means both `Future::get()` and `Future::get(Duration)`
* Using lvalue-qualified `Future::get(...)` has caused 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.
* Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get(...)`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
* Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.

Reviewed By: LeeHowes

Differential Revision: D8799081

fbshipit-source-id: 890a221c84ba4847abfaf6e564b0eceb0176fd54

Summary: Add a data() method to folly::sorted_vector_map and folly::sorted_vector_set which returns a const pointer to the underlying container's data

Reviewed By: yfeldblum

Differential Revision: D8750840

fbshipit-source-id: d361fe21ac741b31b60f551935a3ed8c9549f11a

Summary:
detect FOLLY_HAVE_LIBZSTD by true/false
Pull Request resolved: https://github.com/facebook/folly/pull/885

Reviewed By: terrelln

Differential Revision: D8807276

Pulled By: yfeldblum

fbshipit-source-id: 4372b925a487a31b26cc4c59d7f513639d864f00

Summary:
Optimise the destruction of default-constructed and moved-out Function objects. Instead of calling a function pointer that is set to a no-op function, use `nullptr` to signal emptyness of that function pointer and check if it is `nullptr` before invoking.
This adds additional branching in a few places: not only in the destructor, but also in the move constructor, as well as in the little used `hasAllocatedMemory`. The effect of getting rid of calls to a no-op function pointer should outweigh that.

Reviewed By: djwatson

Differential Revision: D8694003

fbshipit-source-id: 42972805b2ade255cf1dcc98e54985b1524daa73

Summary: AwaitWrapper was previously only working with types which are Awaitable (i.e. have await_ready()/await_suspend()/await_resume()). This extends it to support types which have operator co_await() implemented.

Reviewed By: lewissbaker

Differential Revision: D8580759

fbshipit-source-id: 980f9c9f34c5a2302badb2ab7c4644883b14aa2c

Summary:
This fixes issue #882. Ping terrelln.
Pull Request resolved: https://github.com/facebook/folly/pull/884

Reviewed By: yfeldblum

Differential Revision: D8794382

Pulled By: terrelln

fbshipit-source-id: 52d8a02991d2be401464ed3cd383a45230ba8ca7

Summary:
We should not be able to create tdigest centroids with weight <= 0.
Added a debug assert to ensure this.

Differential Revision: D8786969

fbshipit-source-id: 738f2c8d00596365363ea7be88c759da881ab770

Summary:
Instead of a reader-writer lock in RequestContext data_, use an allocation + hazptr.
This improves setContext/saveContext perf at the expense of setData.

Differential Revision: D8397670

fbshipit-source-id: 105fd715f1eb09499c88d1a205f019ae01a54f13

Summary: This is horrifying. `std::make_optional` is visible w/o `using` anything, making the use of `make_optional` here ambiguous.

Reviewed By: yfeldblum, elsteveogrande

Differential Revision: D8775609

fbshipit-source-id: 4f1162958909dfab603d2c61473155555a05e9d2

Summary:
In furtherance of advancing connection conditioning in dependent code, the
time-point which a connection was established can be read through an
accessor.

Reviewed By: yfeldblum

Differential Revision: D8669627

fbshipit-source-id: 156924689354d7a19188f4873009e678a68be64b

Summary:
Given a tuple, return a tuple of references whose value categories are derived
from the value category of the input tuple

Given this, revert to the exact behavior `MQTTChannel` had prior to D8248199.

Reviewed By: mzlee

Differential Revision: D8698755

fbshipit-source-id: c9b68a3f344c6bae25f612a38f5c22be9b7f87bc

Summary: timeout dosen't take effect for add() of ThreadManager

Reviewed By: andriigrynenko

Differential Revision: D8674748

fbshipit-source-id: a0336fb78182ad432b2d8e5beb61f785e59f0fdd

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

* This is something we should do for safety in general.
* Context: `Future::get(...)` means both `Future::get()` and `Future::get(Duration)`
* Using lvalue-qualified `Future::get(...)` has caused 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.
* Problems with `Future::get(...) &`: it moves-out the result but doesn't invalidate the Future - the Future remains (technically) valid even though it actually is partially moved-out. Callers can subsequently access that moved-out result via things like `future.get(...)`, `future.result()`, `future.value()`, etc. - these access an already-moved-out result which is/can be surprising.
* Reasons `Future::get(...) &&` is better: its semantics are more obvious and user-testable. It moves-out the Future, leaving it with `future.valid() == false`.

Reviewed By: djwatson

Differential Revision: D8711357

fbshipit-source-id: 7b6a4119f4427fbc779b1f9e1c0dd44762021894