Summary: This change introduces CO_* versions of the main GTest ASSERT_* macros that we use in test validation. These are needed as calling ASSERT_* in a coroutine does not work. ASSERT_* embeds a `return` statement, while coroutines need a `co_return` statement.

Reviewed By: ispeters

Differential Revision: D25369376

fbshipit-source-id: dbd95e8c21e28581f93202af4d6fea9245238f5d

folly: utf8ToCodePoint: enforce max valid code point is U+10FFFF - return U+FFFD / throw for well-formed UTF-8 encoded values that are larger than the max code point

Summary:
UTF-8 can encode large numbers, but Unicode code points are only defined up to `U+10FFFF`.

For example:
- the 4B UTF-8 encoding `"\xF6\x8D\x9B\ xBC"` (bits: `11110110 10001101 10011011 10111100`) is a valid UTF-8 encoding
- but the encoded value is `U+18D6 (https://github.com/facebook/folly/commit/d40182262d41679cab28f6be7366cc5ff901683b)FC` which is larger than `U+10FFFF`

With `opts.skip_invalid_utf8 = true;` `json::serialize` should have returned `"\ufffd"` since it the input is invalid, but due to a bug in `utf8ToCodePoint` it returned the incorrect `"\"\xF6\x8D\x9B\xBC\""`.

Update `utf8ToCodePoint` to also reject 4 byte UTF-8 encoded values larger than the max Unicode code point (`U+10FFFF`).

Reviewed By: luciang

Differential Revision: D25275722

fbshipit-source-id: e7daeea834a0c5323923a5451a2565ceff5e4734

Differential Revision: D25307854

fbshipit-source-id: 11b1282659b1b2c20b04e848f0c9824813af5b21

Summary: This change introduces a specialization for string-to-float (32-bit) conversion. It improves fidelity to the numeric value represented by the input string.

Reviewed By: vitaut

Differential Revision: D25239226

fbshipit-source-id: 531aa33aa74aaeeb98d9803bcd10bd7f31654988

Summary: Fix the WriteOptions gso default value - it should be disabled

Reviewed By: danobi

Differential Revision: D25313187

fbshipit-source-id: 581f41d9da48405092eef303630aaa88b18d1da0

Summary:
Today, a continuation of coro or semifuture application handlers will always execute on NORMAL priority thread pool. This is because the effective executor for the task is the `ThreadManager::Impl` and its `add()` implementation does not preserver tasks' priority (which we map into thread pool).

In this change, we wrap each priority/source in a separate keepalive. Generated code is routing either coro or semifuture onto the corresponding keepalive, which is preserved across tasks that do not explicitly specify a target executor.

Reviewed By: andriigrynenko

Differential Revision: D25105971

fbshipit-source-id: 9adaea654b3a099ff4de048026a67bdb588a3c2a

Summary: `makeStaticObserver` is a helper method that returns an observer that never changes in value.

Reviewed By: andriigrynenko

Differential Revision: D25254488

fbshipit-source-id: 1336d0088aff1e5abfa8160bd76e4f61b68eaed8

Summary:
This diff enables aggregation of point-in-time snapshots of the `TDigest`s that represents the state of `BasicQuantileStat`

We capture a `Snapshot` of `TDigest` and `SlidingWindow<TDigest>`.

The diff exposes `TDigest` and `SlidingWindow<TDigest>` to `QuantileStats`.

These objects are wrapped by the structs, `Snapshot` and `SnapshotEntry`, in `BasicQuantileStat` and `BasicQuantileStatMap`, respectively .

Reviewed By: yfeldblum

Differential Revision: D25170883

fbshipit-source-id: 0201a05cc4020851b652ed3a7b602d5b22aa63be

Summary:
Clean up tombstones when copying from a full map.
Equal capacity maps are copied with tombstones for speed but that optimization should not be used if it results in a full map.

Add guarantee that a copy from a map with tombstones will have at least one empty element.

Reviewed By: A5he

Differential Revision: D25230678

fbshipit-source-id: 900b734cc526be8da8be4e70137d19645f994f19

Summary: It took me a while to find that I'd `co_await`'d the same `Task<>` twice when working in a loop. This would've made it easier to find.

Reviewed By: andriigrynenko

Differential Revision: D24718615

fbshipit-source-id: 263c0aae208eab37ab198f875dc72a03287785c1

Summary: If timed_wait is called with an awaitable that has a non-copyable return value then we must std::move the result.

Reviewed By: iahs

Differential Revision: D25222893

fbshipit-source-id: bd3c0ca19d182a464ad4b430f1792dcfff54ffdf

Summary:
Breaks builds.

overriding_review_checks_triggers_an_audit_and_retroactive_review
Oncall Short Name: fbobjc_sheriff

fbshipit-source-id: 8b6437a9e87e4888a6b7a85637232308412cf416

Summary:
This diff adds heterogeneous mutation support to ConcurrentHashMap.
The gating of the allowed key types are done in `EnableHeterogeneousInsert`.

`CHM::insert()` does not destructure `pair` arguments and `CHM::emplace()` does
not yet attempt to identify a usable key, leaving those as future follow-ups.

Reviewed By: yfeldblum

Differential Revision: D23349316

fbshipit-source-id: 3d0b22f5c540d913db6bc93d77481d2ffc4426ac

Summary:
This diff adds heterogeneous lookup handling for `ConcurrentHashMap` (`find()`
and `at()`), which allows lookups on keys that the hasher and key equal
functors accept but are not exactly the same as the `KeyType` of the map.
Common usage of the feature include looking up with a `std::string_view` key in
a `map<string, X>`, thereby avoiding creating an unnecessary temporary string
object.

Reviewed By: yfeldblum

Differential Revision: D23279680

fbshipit-source-id: 0537d23dd6b464cfea7a5b347ecbad9a5ec5bde4

Summary:
Fixes https://github.com/facebook/folly/issues/1449

The current public VS releases (16.3 up to 16.7) have builtins support. In commit https://github.com/facebook/folly/commit/7f1bda25627503ca8af2536cc81298a7d4688375 the #ifdef that was gating the definition of builtins was removed, as 16.8 will remove it. However by removign this gate, it makes current VS versions unable to build folly which breaks projects like react-native-windows.

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

Reviewed By: yfeldblum

Differential Revision: D23702071

Pulled By: Orvid

fbshipit-source-id: 6e05f63293e68783b6caae68cc5bd80ad3679766

Summary: During intensive builds using all available cores tends to crash the machine. Cutting default number of jobs by half prevents that.

Reviewed By: wez

Differential Revision: D25027757

fbshipit-source-id: 5ea6c77fe4363b9ee09e50de1a5cc33281872e1d

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

Differential Revision: D25156288

Pulled By: yfeldblum

fbshipit-source-id: 01c9e6898158e9651367144c22f215ef75ff7ae3

Summary: Added yaml-cpp library to the fboss OSS build

Reviewed By: shri-khare

Differential Revision: D25126509

fbshipit-source-id: 1e88150dbf8c96a5ac696e003265dc1f14bec105

Summary: The new library firmware_storage needs the yaml-cpp. For OSS build this diff adds the yaml-cpp library to manifest

Reviewed By: shri-khare

Differential Revision: D25115387

fbshipit-source-id: 9ed1c374df7e87f284c48d366095a20183719534

Reviewed By: yfeldblum

Differential Revision: D24739525

fbshipit-source-id: 1ad55b470dd305dea6f3c7eeb56890ea6b59d252

Differential Revision: D24757714

fbshipit-source-id: 1a494c5eb758480431d5aa70861359e67e9f831c

Summary:
The fix was part of D22249713 / D24571536. However, the error is not specific to
uint8/16 support. Let's fix it right away.

Reviewed By: ot

Differential Revision: D24629540

fbshipit-source-id: 8cbc3226259d49ec3e64c03ca55f3ef1ac5b981d

Summary:
Updates the co_awaitTry() adapters to support the co_withAsyncStack()
CPO.

This required updating the WithAsyncStackAwaitable to also support
co_awaitTry() but having its wrapper awaiter type also forward through
the .await_resume_try() method if one exists.

Modified the is_awaiter trait check to no longer check for a valid
await_suspend() call as some awaiters returned from co_withAsyncStack()
now require coroutine_handle<Promise> and no longer accept the
coroutine_handle<void> parameter previously checked by the trait.

Reviewed By: andriigrynenko

Differential Revision: D24499833

fbshipit-source-id: fdcb99a2b85c4235bcd4b5dcc12cf79cb414f034

Summary:
The stack-traces for child worker tasks launched to process each
incoming AsyncGenerator now have the same common consumer-task
as the parent frame, which is then a detached-task, rather than
each of the child workers being their own detached tasks.

Reviewed By: andriigrynenko

Differential Revision: D24480161

fbshipit-source-id: c02887abf676bde9b297ee6d8f0fcabe959616e3

Summary:
This should allow stack-traces for a chain of async work that was launched
using blockingWait() to continue tracing the normal stack-frames of the caller
of blockingWait().

Reviewed By: andriigrynenko

Differential Revision: D24479522

fbshipit-source-id: e0604ed43edbd9df51daf679e0adf06d934a3ca6

Summary:
Modify the AsyncScope::add() method so that it records the call-site of .add()
as the first frame's return address instead of recording .add() itself as the
first frame.

This should hopefully give a bit more insight into where the detached task was
launched.

Reviewed By: andriigrynenko

Differential Revision: D24478808

fbshipit-source-id: 0723891e77af5e52c7f8c13e218e4fb9120867e3

Summary:
The collectAll() family of algorithms now hooks up async-stack frames
of child operations to ensure that they trace back up through to the
caller of collectAll() rather than stopping at the call to .start()
inside collectAll().

This also adds the helper `folly::coro::detail::co_current_async_stack_frame` which
allows the coroutine to get access to its own AsyncStackFrame
object - which is needed for algorithms like collectAll() which
then need to pass this on to the BarrierTask when it is started.

Reviewed By: andriigrynenko

Differential Revision: D24466130

fbshipit-source-id: f7058388ebc8fa212684eb0edc0a83deef6fc2a2

Summary:
It now saves and restores the async stack frame natively which
avoids creation of a wrapper coroutine to do this.

Reviewed By: andriigrynenko

Differential Revision: D24464577

fbshipit-source-id: 965893a7f2e30c0759fb1970784500c96ed8a8ac

Summary:
This should avoid creating two temporary wrapper coroutines to apply
both co_viaIfAsync() and co_withAsyncStack() to awaitables when awaited
within a Task/AsyncGenerator coroutine.

The default co_viaIfAsync() implementation now customises the
co_withAsyncStack() CPO and saves and restores the async frame
itself if the wrapped awaitable does not support async stacks,
or otherwise passes the async frame through to the child awaitable
if it does support async stacks.

Reviewed By: andriigrynenko

Differential Revision: D24464513

fbshipit-source-id: f9751030f3c1d2725a00cb803ee46ee12dddb2ed

Summary:
The DetachedInlineTask coroutine type now has its own AsyncStackFrame.

While this is largely an internal implementation detail used only
for the TaskWithExecutor's `.start()` family of methods, this now
means that detached tasks launched using TaskWithExecutor's
`.start()` methods will now record the return-address of the call to
`.start()` in the stack-trace and will also have the async-stack begin
with the `detached_task` frame at the top-level.

Reviewed By: andriigrynenko

Differential Revision: D24440817

fbshipit-source-id: 861f1ca46ec4a28b5b7e388bb8b243e4d597ee0d

Summary:
AsyncGenerator coroutines now have their own AsyncStackFrame and so can
participate in async call-stack tracing.

AsyncGenerator now applies co_withAsyncStack() to all awaitables
awaited from within the generator coroutine.

The NextAwaiter now implements the co_withAsyncStack() CPO to advertise
that it will save/restore the awaiting coroutine's AsyncStackFrame if
it provides one.

This allows the AsyncGenerator to symmetric-transfer to awaited Task
coroutines and vica-versa. This fixes some stack-overflow issues with
some synchronously-completing use-cases of AsyncGenerator.

Reviewed By: andriigrynenko

Differential Revision: D24437278

fbshipit-source-id: f9612d54558b961bb023460d4a118a773022737b

Summary:
`BarrierTask` and `DetachedBarrierTask` coroutines now have their own `AsyncStackFrame`.

This means that when a `Task` executes `co_await barrier.arriveAndWait()` that we
can use symmetric transfer to resume the `Task` since the `BarrierTask` will
already have an active `AsyncStackRoot` that we can reuse.

This fixes the test for stack-overflow of synchronously completing coroutines that
use `collectAll()` algorithms (which internally use `BarrierTask`).

Reviewed By: andriigrynenko

Differential Revision: D24435340

fbshipit-source-id: 87b622e8083f6c8f2b12f6b2f4b0bccd8bd5a595

Summary:
Initial diff that adds support for tracing through a chain of folly::coro::Task coroutines.

This adds some scaffolding that handles saving/restoring the active AsyncStackFrame
when a Task awaits some awaitable type that does not know about AsyncStackFrame
objects but also allows awaitables to opt-in to AsyncStackFrame awareness by
customising the new `folly::coro::co_withAsyncStack()` CPO.

Currently only `Task` and `TaskWithExecutor` awaiters have customised this CPO.

Also updated the awaiters for `Task` and `TaskWithExecutor` to handle being awaited
from coroutines that are not async-stack aware - in which case they just record a
null parent-frame for the Task.

The Task's `final_suspend()` then either deactivates or pops the frame depending
on whether there was a parent frame recorded.

BUG: This change currently breaks the symmetric-transfer stack-overflow avoidance
when awaiting synchronously-completing coroutines from an AsyncGenerator or from
a BarrierTask (eg. inside collectAll implementations).

Reviewed By: andriigrynenko

Differential Revision: D24428736

fbshipit-source-id: 5722e511ad10d95198ae70a5afe567d83cb06285

Summary:
Paths are not necessarily legal glob syntax. In particular, backslash
is used for escaping. This caused problems on Windows, where we tried
to pass a backslash-delimited path into `eden prefetch --no-prefetch`.

Reviewed By: xavierd

Differential Revision: D25072784

fbshipit-source-id: 9ce8e5ccc8f28581512c39d04922889da0bc1bf6

Differential Revision: D25018383

fbshipit-source-id: eefc622ad60d663efd174ad341df7697c548b3bd

Summary: Fix a double delete issue

Reviewed By: danobi

Differential Revision: D25005179

fbshipit-source-id: 03ae8f0722316294979ec7511ef9ac794196a7ce

Summary: Fix for: https://github.com/facebook/wdt/issues/203

Reviewed By: vitaut

Differential Revision: D24954835

fbshipit-source-id: 92f29f71cd6eef9bdcbe92ed1ecb8f1f5d24326e

Reviewed By: andriigrynenko

Differential Revision: D24880761

fbshipit-source-id: 643da2b0fd461955ea33b4ba48f377c30720d442

Summary: The worker thread just needed to be killed before the `AcceptCallback`. `AsyncServerSocket` calls a method on this callback class in its dtor, so it must either be alive or removed using `removeAcceptCallback`.

Differential Revision: D24972293

fbshipit-source-id: 2c7b6d64c2b9b8c00d03107002fa31e565df2a01

Summary:
Added a timestamp to `AsyncServerSocket::QueueMessage` so that `NotificationQueue` can ignore new connection messages which are deemed *expired*. Expired messages represent sockets which have *probably* timed out already.

The TTL is configured per `AsyncServerSocket` instance and is applied to all future messages that are queued by it. By default, messages do not expire. This can be configured with `AsyncServerSocket::setQueueTimeout`.

Reviewed By: andriigrynenko

Differential Revision: D24667870

fbshipit-source-id: 0f9d6c235627393d964e280a0d5956676010c7aa