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

Summary:
In the same vein as some previous diffs: some `boost` headers are expensive.  These `iterator_facade` and related headers (which include -facade.h) are examples of super expensive ones.

`boost/iterator/iterator_adaptor.hpp` in particular shows up as being responsible for appx. 7.5% (avg) of translation units built.

The solution here is: since this bloats `folly/dynamic-inl.h`, in that "private" impl file, I added a workalike class, which is minimal and works well enough to do the job for dynamic's iterators.

Reviewed By: yfeldblum

Differential Revision: D8329532

fbshipit-source-id: deaab7b52d110cd29c613d687a6a74c6a42b515d

Summary:
Iterator helper classes are used in several places around Folly; they're convenient because they take care of some of the details while letting your class provide only a few of the necessary pieces.

Boost has `iterator_facade` and `iterator_adaptor` to help in these cases, but the header for these classes are absurdly expensive to include (their transitive includee tree is quite large).

For this reason, we'll add similar helper classes, with minimal dependencies, under detail.  In subsequent diffs we'll migrate some existing code using these boost classes (or implementing iterators itself) to use these helpers.

Reviewed By: yfeldblum

Differential Revision: D8345073

fbshipit-source-id: 3e6656e544349fe228358074de30c89c805e2628

Summary: [Folly] Fix incorrect copy constructions in `ConcurrentHashMap`, where the `ConstIterator` is move-only but the code attempts to copy it.

Reviewed By: magedm

Differential Revision: D8678003

fbshipit-source-id: 89d47b811fb27ecbbd42cae03a2af13becd0082a

Summary:
[Folly] `invoke_type` members for free- and member-invoke traits containers.

Usable as:

```
FOLLY_CREATE_FREE_INVOKE_TRAITS(swap_invoke_traits, swap, std);
// ...
swap_invoke_traits::invoke_type my_swap;
my_swap(obj1, obj2);

Reviewed By: aary

Differential Revision: D8670799

fbshipit-source-id: 0c24912721aa20ca9647261e24ed3eb0e340ab20

Summary:
[Folly] Refactor apply-invoke traits. Can make them smaller by extracting a common denominator and then falling back on the base invoke traits.

Also fixes the build for MSVC2015.

Reviewed By: aary

Differential Revision: D8676590

fbshipit-source-id: f59c7014d3294f3b0978c2fd027cf3a87411f639

Summary:
If `MemoryIdler` is used with threads that are backed by huge pages, the
`madvise(..., MADV_DONTNEED)` calls will fail with an `EINVAL`. Prior to this
diff, this would lead to an assertion failure. Now, if `EINVAL` is returned, we
warn the user, as `MemoryIdler` may not be able to function as expected.

Reviewed By: yfeldblum

Differential Revision: D8669399

fbshipit-source-id: f97ea7549deffdbf283b3516b9e8feafe18a036c

Summary: [Folly] Simpler free-invoke traits. Only supports one namespace housing a base definition. For the typical case of `swap`, with a base definition in `namespace std`, this works.

Reviewed By: aary

Differential Revision: D8666221

fbshipit-source-id: abfd302e430ad7151c119e98a706201265d302d3

Summary: Make the pthread key a singleton

Reviewed By: yfeldblum

Differential Revision: D8663589

fbshipit-source-id: 1e0c328104bd8c3d3c689dc4955a185336e74276

Summary:
`throw` within a `noexcept` function triggers a compiler warning on the latest clang in C++17 mode.

As the behavior of uncaught `throw` within a `noexcept` context is to terminate the program, do so explicitly.

Reviewed By: yfeldblum

Differential Revision: D8651221

fbshipit-source-id: 004c4c132ad9b5b873a92cf2710b9d1ebe4e705b

Summary:
The compiler will likely remove the branch on destruction because
it's never used

Reviewed By: yfeldblum

Differential Revision: D8651868

fbshipit-source-id: ef16b9d11569f72aa0fa89cb6aa2450a58d783e7

Summary:
D8395569 added a prefetch instruction as part of iterator advance
for F14Value and F14Node maps.  This caused the work to advance the
iterator returned by erase to no longer be recognized as dead code by the
GCC optimizer.  This diff separates out advance() and advanceLikelyDead()
methods, avoiding prefetch in the latter case.

Reviewed By: shixiao

Differential Revision: D8656038

fbshipit-source-id: 86cecf40e8622f815d34a98709b90d6ef73dd618

Summary:
D8586283 added an implicit conversion from allocator_type to a
uint8_t-rebound allocator, but allocators might provide only an explicit
rebinding constructor.  This diff makes F14 use the explicit form.
It also adds a binary that when debugged (in a buck build environment)
is useful for evaluating code size.

Reviewed By: shixiao

Differential Revision: D8655289

fbshipit-source-id: c977edb041ce2056f3ce23c52a7f8464a6b9f1bd

Reviewed By: igorsugak

Differential Revision: D8653359

fbshipit-source-id: 5bb33792aa96a0ed7f88a672100955f366c568da

Summary: [Folly] Free function invoke traits.

Reviewed By: andriigrynenko

Differential Revision: D8632204

fbshipit-source-id: 1f5f6e31072ef3a711edab02b6b7bbad8c894a95