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

Summary:
Some people said the read-lock-when-const behavior of the `SYNCHRONIZED` macro
was desirable, so instead of codemodding the `SYNCHRONIZED` macros out of
existence in favor of `withRLock`, `withWLock` and `withLock`, add a
generalization of the `SYNCHRONIZED()` macros, so they can be removed in favor
of this, which has identical behavior while being more general.

Reviewed By: yfeldblum

Differential Revision: D8248203

fbshipit-source-id: eb3c1444182e42bea79a377a66606d91a6e517bd

Summary: IOBuf's custom iterator was changed so that it would no longer need `<boost/iterator_facade.hpp>`.  Change again so that it uses Folly's own (cheap) header file providing roughly the same functionality.

Reviewed By: yfeldblum

Differential Revision: D8345072

fbshipit-source-id: bbbfb4373e72444a5e54aeccafd2d316ebdbae63

Summary:
Don't zero-initialize Data.  It's already set in all the constructors we care about,
and gcc generates pretty aweful code for this.

Reviewed By: ot, spacedentist

Differential Revision: D8678393

fbshipit-source-id: 55a46f3db376ba1f9aa8100f176fd7d8ac18275c

Summary:
Adds two benchmarks for small create/move/invoke,
and both small and large for move, and function ptr move.

Reviewed By: yfeldblum

Differential Revision: D8678386

fbshipit-source-id: c78c493587df5d960b603178147d591489c7f519

Summary: Future unwrapping in defer is broken for incomplete Futures and SemiFutures with deferred work.

Reviewed By: yfeldblum

Differential Revision: D8675535

fbshipit-source-id: 8deff362ea018cf4717354cd973756161c4249aa

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

Codemod steps (where `get(...)` means both `Future::get()` and `Future::get(Duration)`):

* expr.get(...) ==> std::move(expr).get(...)  // if expr is not already an xvalue
* expr->get(...) ==> std::move(*expr).get(...)

Note: operator precedence of that last step is safe - no need to parenthesize `expr`. Reason: `->` binds more tightly than unary `*`.

Reviewed By: yfeldblum

Differential Revision: D8683752

fbshipit-source-id: 593bcd92ca4e11244e0f912cf956538889a2c777

Summary:
We built folly with upcoming Visual Studio 15.8, which failed with the following message:
error C2338: You've instantiated std::aligned_storage<Len, Align> with an extended alignment (in other words, Align > alignof(max_align_t)). Before VS 2017 15.8, the member type would non-conformingly have an alignment of only alignof(max_align_t). VS 2017 15.8 was fixed to handle this correctly, but the fix inherently changes layout and breaks binary compatibility (only for uses of aligned_storage with extended alignments). Please define either (1) _ENABLE_EXTENDED_ALIGNED_STORAGE to acknowledge that you understand this message and that you actually want a type with an extended alignment, or (2) _DISABLE_EXTENDED_ALIGNED_STORAGE to silence this message and get the old non-conformant behavior.

This enables the `_ENABLE_EXTENDED_ALIGNED_STORAGE`.

Closes https://github.com/facebook/folly/pull/881

Reviewed By: Orvid

Differential Revision: D8689152

Pulled By: yfeldblum

fbshipit-source-id: fada301a163b0b09adc76807dc0e7bd26d9740a9