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

Summary: The `size_` and `upperBound_` fields can be const-qualified.

Reviewed By: ot

Differential Revision: D8734943

fbshipit-source-id: ced8a7c96442772a37bb8be373c71b557598257f

Summary:
`LockedPtr`s were not constructible from other `LockedPtr`s with different
lock policies even if their unlock policies were the same.

Fix that.

Reviewed By: simpkins

Differential Revision: D8722292

fbshipit-source-id: bf17f86bef9ceb8e994a2bd01e66d61dbd51bb12

Summary: This diff fixes the typo in `tryTo` declaration for `enum`s and adds test coverage for enum specialization.

Reviewed By: yfeldblum, shixiao

Differential Revision: D8694574

fbshipit-source-id: d20e34d7d7bae7805cc7c31507cffb292235bdfc

Summary: This fixes a race in AwaitWrapper, but also makes it easier for compiler to perform the heap elision optimisation.

Differential Revision: D8701500

fbshipit-source-id: 86efd5089ac7fdf32f64b3d84fcbfbefb9824365

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`.

Reviewed By: yfeldblum

Differential Revision: D8704033

fbshipit-source-id: 246f35c6320425e4b76ad11882bf55169988b772

Summary: Previously this code failed to build due to ambiguity between folly::apply and std::apply

Reviewed By: aary, ot, luciang

Differential Revision: D8705541

fbshipit-source-id: 575c52517792a930d3639b39eba4abc352739d6f

Summary: When people using Static Tracepoint with Semaphore, they'll need to define / declare it. That would cause error on non-supported platforms. This Diff adds empty statement for them.

Reviewed By: myreg

Differential Revision: D8706499

fbshipit-source-id: 2978faf08c451d19e44156308d896e7cac83fcc7