Summary:
Certain toolchains on iOS platforms don't apply EBO to F14 BasePolicy and
F14Table, which makes the size calculations incorrect.

This diff disables the test pending further investigation (T33121191).

Reviewed By: nbronson

Differential Revision: D9467473

fbshipit-source-id: 50435b3fcdeb81a6a892e280fdc919486f0ed107

Summary: Update cmake configurations + legocastle jobs in order to add fizz as a dependency to wangle

Reviewed By: reanimus

Differential Revision: D9337956

fbshipit-source-id: 40f25694c2b3fd8aa37d254bc63a664f4c8ee526

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).onError(...)` instead of `f.onError(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Codemod changes:

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

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

Reviewed By: LeeHowes

Differential Revision: D9445122

fbshipit-source-id: 1202bc2dd2e054b541458aa20829abe4c7f52b33

Summary: The message is useful once, but not for every time the header is included and the condition checked.

Reviewed By: shixiao

Differential Revision: D9457501

fbshipit-source-id: 35c2c2f0510e9be9b747ab7c760a7cc36ad500b4

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).semi()` instead of `f.semi()`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: LeeHowes

Differential Revision: D9442672

fbshipit-source-id: ea0e97915b8143e2f36e956be708dc36a735cca5

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).within(...)` instead of `f.within(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: LeeHowes

Differential Revision: D9442173

fbshipit-source-id: 910914fd9da80627b335419542b5bb358b21f680

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).onError(...)` instead of `f.onError(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: LeeHowes

Differential Revision: D9441271

fbshipit-source-id: c65614a5529bf50bb9a209e3941d20f3688f2a80

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).thenMulti(...)` instead of `f.thenMulti(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: LeeHowes

Differential Revision: D9437727

fbshipit-source-id: 7656aff65db69a5cb51b621b7d7b1b01ef0d3e12

Summary:
These conversions enable a few bits of folly to compile with
more stringent compiler warnings than the baseline.  One site actually
had a bug in an error path, the rest are just churn.

Reviewed By: sathyaphoenix

Differential Revision: D9398429

fbshipit-source-id: d9836eabe93be7aeebd59581df8fb6d278c74112

Summary: MSVC is having issues with this, so explicitly refer to `AllocTraits` via `Super`.

Reviewed By: wez

Differential Revision: D9387914

fbshipit-source-id: 1751b029d678151cbce90cdffdce586498cdf756

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).thenMulti(...)` instead of `f.thenMulti(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: LeeHowes

Differential Revision: D9415878

fbshipit-source-id: 3dd78941c60ee41f4284b5842e57c1c25005d15a

Summary:
Introduce a RequestToken class to RequestContext.  Map indicies are now uint32_t.

New interfaces are exposed using RequestToken, previous std::string interface forwards
to new interface.  This is a regression for the previous std::string interface since it
must do two hash lookups now, however, the new interface is faster.

Reviewed By: A5he

Differential Revision: D9197415

fbshipit-source-id: ffb8be51c609233fecfdff205a3ea4d4bb68de4b

Summary:
Non-functional comment-only changes.

Goal: Adjust Promise's code-docs so they are consistent with Future and SemiFuture, e.g., change "valid() must be true" to "`valid() == true`"

Reviewed By: LeeHowes

Differential Revision: D9415137

fbshipit-source-id: dbb8df00919779b339e5b08337eba0df1a210ac2

Summary:
This is a non-functional comment-only change.

Reason: doc-comment tools interpret embedded code-blocks via 2-space-indentation instead of "```"

Reviewed By: LeeHowes

Differential Revision: D9414916

fbshipit-source-id: d7dd29b0d67f1a361a99fba5b95aa3a6e095041c

Summary:
Support 4-byte UTF-8 strings.

https://en.wikipedia.org/wiki/UTF-8
| Number of bytes | Bits for code point | First code point | Last code point |   Byte 1 |   Byte 2 |   Byte 3 |   Byte 4
|               1 |                   7 |           U+0000 |          U+007F | 0xxxxxxx
|               2 |                  11 |           U+0080 |          U+07FF | 110xxxxx | 10xxxxxx
|               3 |                  16 |           U+0800 |          U+FFFF | 1110xxxx | 10xxxxxx | 10xxxxxx
|               4 |                  21 |          U+10000 |        U+10FFFF | 11110xxx | 10xxxxxx | 10xxxxxx | 10xxxxxx

`utf8ToCodePoint` now correctly returns the code point for 4-byte UTF-8 strings.

The JSON standard (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf) says:

> Any code point may be represented as a hexadecimal escape sequence. The meaning of such a hexadecimal
number is determined by ISO/IEC 10646. If the code point is in the Basic Multilingual Plane (U+0000 through
U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the
lowercase letter u, followed by four hexadecimal digits that encode the code point. Hexadecimal digits can be

This was the behavior implemented for 2-3-byte UTF-8 strings which all fit in the U+0000 through U+FFFF range (see above diagram).

> To escape a code point that is not in the Basic Multilingual Plane, the character may be represented as a
twelve-character sequence, encoding the UTF-16 surrogate pair corresponding to the code point. So for
example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E".
However, whether a processor of JSON texts interprets such a surrogate pair as a single code point or as an
explicit surrogate pair is a semantic decision that is determined by the specific processor.

When `encode_non_ascii == true` we now also support encoding 4-byte UTF-8 strings as 2 UTF-16 surrogate pairs.

Reviewed By: ot

Differential Revision: D9357479

fbshipit-source-id: 5c47bee4e71d5888b8264d8d3524d2084769adb0

Summary:
It may be surprising to some users of AsyncSocket that buffered
writes always result in a success/error callback, even on shutdown.
This commit explicitly documents this part of the API and adds
some suggestions on how to handle it.

Reviewed By: simpkins

Differential Revision: D9405722

fbshipit-source-id: 07c2d1caa2c7c023592f734f7ced1ebbcbf4c628

Summary:
Some of the test cases are only appropriate for the F14 version with vector
instructions. Move or delete those that should not be run for the fallback
version.

Reviewed By: nbronson

Differential Revision: D9405419

fbshipit-source-id: 99c3dd689c157da71e36f4f315c0b6982203b174

Summary:
After an innocent inclusion of "folly/futures/Future.h" in some cachelib code (D9372014), some gcc builds fail with:
    folly/detail/MemoryIdler.h:88:30: error: conversion to 'float' alters 'long unsigned int' constant value [-Werror=float-conversion]

It seems like this has been worked-around previously by ignoring warnings in outer code such as here:
diffusion/FBS/browse/master/fbcode/cachelib/common/Utils.h$7-10

Reviewed By: yfeldblum

Differential Revision: D9381592

fbshipit-source-id: 00ec25600ae473baeee5caaef9989d66a9a64a59

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).ensure(...)` instead of `f.ensure(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329325

fbshipit-source-id: 546f6da2dc59b2676c017fe83c3b5a9cfad19e3f

Summary: [Folly] Implement `allocate_unique` without `catch` to support `-fno-exceptions` case.

Reviewed By: danzimm

Differential Revision: D9384180

fbshipit-source-id: 8550ad21be2e3eaf4e868ab6866b849828b3d0de

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unit(...)` instead of `f.unit(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329200

fbshipit-source-id: e8a60498f5ff8a15700c7b0fb0aba5a6faf83da1

Summary:
Adds four template metafunctions that can be used when building generic coroutine code.

- `is_awaitable<T>`, `is_awaitable_v<T>`
  Query whether a type can be co_awaited within a "normal" coroutine.
- `is_awaiter<T>`, `is_awaiter_v<T>`
  Query whether a type implements the `await_ready()`, `await_suspend()` and `await_resume()` methods required for the 'Awaiter' concept.
- `awaiter_type<T>`, `awaiter_type_t<T>`
  Query what the 'Awaiter' type is for a given 'Awaitable' type. This will be the return-type of whatever `operator co_await()` returns, if one is defined, otherwise is type of the Awaitable itself.
- `await_result<T>`, `await_result_t<T>`
  Query what the type resulting from applying the `co_await` operator to a value of type, `T`.
- Moved the existing `folly::coro::get_awaiter()` implementation from 'AwaitWrapper.h' into 'Traits.h'.

Note that these traits all currently assume that the `co_await` operator appears within a coroutine that does not provide an `await_transform()` customisation point. A promise type that implements the `await_transform()` customisation point can arbitrarily change the behaviour of a `co_await` that occurs within its body.

Reviewed By: andriigrynenko

Differential Revision: D9382593

fbshipit-source-id: e9ddfec4a62579a4b2649c070e53e8639e7c68a1

Summary: Introduction of `folly::IOBuf::wrapIov` and the subsequent change to `WriteChainAsyncTransportWrapper` introduced a subtle change where someone sending a number of 0 length iovs would still get their WriteCallback invoked.   This fixes that case and also invokes WriteCallback if no iovs are to be wrapped.  Arguably, both of these are invalid uses of the API, but this at least fixes the subtleties.

Reviewed By: knekritz

Differential Revision: D9379661

fbshipit-source-id: 73d2f7cd1494be4ccccaa9c1fd834ae5410d6421

Summary:
The API deleted here was added to plan for use in proxygen downstream client auth but we ended up using better alternatives. Given how the wangle pipeline works caller to the getter may never get things other than success (if it's error, connection is closed and pipeline won't flow to the point) without complex OpenSSL callback setup. As a result, it's very unlikely to be used in the future.

Let's just remove them to avoid confusion.

Reviewed By: yfeldblum

Differential Revision: D9361517

fbshipit-source-id: 75d1cf71ee88a5a9ec28a151ddd4ea4aaf9506ed

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unwrap(...)` instead of `f.unwrap(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329273

fbshipit-source-id: fbcda4310fe4d008b7c7595d320d15e3581f09c1

Summary:
Remove the `waitAsync()` method from `folly::coro::Baton` and provide an `operator co_await()` instead.

 This moves the method to be consistent with other folly::coro APIs that use the convention of prefixing the method with co_ when the return-value is an awaitable type.

 In this case it seemed better to allow `co_await baton;` rather than use the potentially confusing `co_await baton.co_wait()` method as the `co_wait` method name seemed too close to and easily confused with the `co_await` keyword.

Reviewed By: andriigrynenko

Differential Revision: D9308773

fbshipit-source-id: 922793a83306e5b1e5e60c69b47b98a9bdd17d8d

Summary: D9197722 added new files, but did not add them to makefile.am

Reviewed By: AjanthanAsogamoorthy

Differential Revision: D9361032

fbshipit-source-id: f398619424969594bb9af9b76d475cb23d1a97e5

Summary: [Folly] Add `noexcept` specifier to `hash_combine` and `hash_combine_generic`.

Reviewed By: nbronson

Differential Revision: D9346979

fbshipit-source-id: 201700019ae9fc5046deac3ed083105abe565382

Summary: Constructing an `exception_wrapper` from an `std::exception_ptr` and a reference to an exception could never throw an exception, but was not marked `noexcept`. So annotate it.

Reviewed By: yfeldblum, lewissbaker

Differential Revision: D9351489

fbshipit-source-id: 858299330b376360fc6420b6c901ab846d577854

Summary: Pull Request resolved: https://github.com/facebook/folly/pull/912

Reviewed By: Orvid

Differential Revision: D9344568

Pulled By: yfeldblum

fbshipit-source-id: bcafaab895454f21c3005825003916d771210d33

Summary: [Folly] Let `hash_combine_generic` take hasher instances as parameters v.s. taking hasher types as template parameters. This would permit its use with non-default-constructible hasher types (if any exist).

Reviewed By: nbronson

Differential Revision: D9330419

fbshipit-source-id: 2fb306e16603c07812559c47e31d7a9e2edcb072

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unwrap(...)` instead of `f.unwrap(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Codemod changes:

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

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

Reviewed By: LeeHowes

Differential Revision: D9350632

fbshipit-source-id: 54806eb982cf22c4c29d326d8ba894837125f291

Summary: Adds a crc32_combine function to folly (and crc32c hardware)

Reviewed By: yfeldblum

Differential Revision: D7687302

fbshipit-source-id: 86393c54776fa63ecfb34e9a589256e92505eeae

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).filter(...)` instead of `f.filter(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329311

fbshipit-source-id: a2640ffe8c70addee9f9ce3614281aa337acaaaf

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

* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).reduce(...)` instead of `f.reduce(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9329242

fbshipit-source-id: 4f192863e69c12484578db6f756de82b97c4427b

Summary:
Update the TDigest interface to accept unsorted or sorted data.
If unsorted, use a custom radix sort explicitly aimed at this use case:
doubles only, assume small data, so we don't use in-place and everything still
fits in cache (1000-10000 items).

Previously D8875766.  This version does not require newer boost versions, and puts
everything in the heap, so there should be no fiber overflows.

Reviewed By: yfeldblum

Differential Revision: D9197722

fbshipit-source-id: 10088cf14d1ff88e1072c00084e09129271e97ec

Summary: [Folly] Cut config-time detection of `cplus_demangle_v3_callback` and the forward declarations and copy-pasting symbols, replacing them with `__has_include(<demangle.h>)`.

Reviewed By: Orvid

Differential Revision: D9287760

fbshipit-source-id: 4464ec22dd6f96cf081cda6051bebe4d41813390

Summary:
Adding an implementation of X509_get0_tbs_sigalg for pre-1.1.0
versions of OpenSSL

Reviewed By: fredemmott

Differential Revision: D9317612

fbshipit-source-id: b7d270a818f802d7df537cdb23e2129dfb184567

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).unit()` instead of `f.unit()`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9308405

fbshipit-source-id: 3ae0001deef1aef203454112757f8f64c47831fc

Summary:
This is part of "the great r-valuification of folly::Future":
* This is something we should do for safety in general.
* Several of folly::Future's methods are lvalue-qualified even though they act as though they are rvalue-qualified, that is, they provide a postcondition that says, in effect, callers should act as though the method invalidated its `this` object (regardless of whether that invalidation was actual or logical).
* This violates the C++ principle to "Express ideas directly in code" (see Core Guidelines), and generally makes it more confusing for callers as well as hiding the actual semantics from tools (linters, compilers, etc.).
* This dichotomy and confusion has manifested itself by 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.
* The goal of rvalueification is to make sure methods that are logically rvalue-qualified are actually rvalue-qualified, which forces callsites to acknowledge that rvalueification, e.g., `std::move(f).filter(...)` instead of `f.filter(...)`. This syntactic change in the callsites forces callers to acknowledge the method's rvalue semantics.

Reviewed By: yfeldblum

Differential Revision: D9308741

fbshipit-source-id: 671b1b7a39f16bcc20ad9f584ed0ca8def53d21c