Summary:
- Fix up wrong order of template arguments in Expected generic
  - Create tests to check up all 3 forms of swap for Expected

Reviewed By: ericniebler

Differential Revision: D9013316

fbshipit-source-id: d4cebd83b268a4c5c551ac970f67b598f117fa73

Summary:
Despite the standard, `std::vector<bool>::const_reference` is not `bool` in
libcpp: http://howardhinnant.github.io/onvectorbool.html

Add the implicit ctor so that `f(dynamic)` can be invoked with `f(v[idx])`
where `v` is a `const vector<bool>` under libc++.

Reviewed By: ot

Differential Revision: D8992805

fbshipit-source-id: 0675174c2a247257238bb11b2c7b319653fe92a3

Summary:
Per title
I found that it was easier to bypass setContext (and not extend RequestContextScopeGuard) to achieve this result.

setShallowCopyContext now directly set the copy as current
the new unsetShallowCopyContext exclusively calls set/onset for the context data that was overriden. This assumes that cost will be fine because the callbackData_ sets are small or empty.
Similar reason they were split from requestData_ in the first place, for RequestContextScopeGuard efficiency.

(Note: this ignores all push blocking failures!)

Reviewed By: andriigrynenko

Differential Revision: D8943668

fbshipit-source-id: ad99177429de6b7b65bf95fa0e94334d73c3750d

Summary:
This guard maintains all the RequestData pointers of the parent (through shallow copy).
This allows to overwrite a specific RequestData pointer for the scope's duration, without breaking others.

We decided to keep the raw ptr interface, which required to implement a pseudo shared ptr to achieve the shallow copy behaviour.
Rest of the code is pretty straight forward. A few more lines than expected, due to introducing overrideContextData to avoid unecessary memory management (clearData) or warnings (setData).

The performance should be neutral for code not using the guard (std::atomic incr/decr).
The guard itself is pretty efficient at copying the values, though there is a slight worry about the keys (std::string). This might be a generic concern about current implementation, some form of cheap static would be better.
It also calls unecessarily onSet/onUnset. I will fix on top as it makes the change more complex.

Reviewed By: djwatson

Differential Revision: D8911351

fbshipit-source-id: 1692428382ace1d0b79bbc84a1db50efb4c7b489

Summary: This added significant cost, it will take effort to deploy, reverting for now

Differential Revision: D9007024

fbshipit-source-id: 04074b09a1a2b7f9b57e3d755a2754657dda21c2

Summary: Allow map to take a SemiFuture vector by changing the way the return type is deduced. Add overloads that take executor to apply.via and run the mapped tasks on a specified executor, and additionally return a Future that completes on that executor.

Reviewed By: andriigrynenko

Differential Revision: D7559540

fbshipit-source-id: f9480ea89fcfaa25a050ee7428dc69de300ccfde

Summary: Non-template functions in header files have to be marked as inline to avoid linker errors.

Reviewed By: yfeldblum

Differential Revision: D8983661

fbshipit-source-id: 8f003e9f4e2d40cb6122da8e9e0adacab00ed0fa

Summary:
When the param type is larger than `unsigned int`, the wider type `size{}` was
implicitly converted to the return type `unsigned int` in `findLastSet`. This
diff makes the conversion explicit.

Reviewed By: yfeldblum

Differential Revision: D8971589

fbshipit-source-id: 8828504c462e9296b84a746bcb7f701bc4a7d20e

Summary: Make ThreadEntry::elementsCapacity atomic

Reviewed By: yfeldblum

Differential Revision: D8963304

fbshipit-source-id: 0b37bbe97475a400e9b574b8285bde8f38a479f5

Summary:
Xcode wasn't impressed when I tried to import `folly::FixedString` from a Objective-C++ context.

This seem to satisfy Xcode's toolchain.

Reviewed By: lambdapioneer

Differential Revision: D8855137

fbshipit-source-id: 7bb3b1039b30241797ec7f3df7c0bbdeffca87bf

Summary:
There should be no expectations on what hash is internally used in dynamic, so
we don't need to maintain compatibility with `fbstring`, which hasn't been used
as string storage in `dynamic` for quite a while.

Reviewed By: yfeldblum, ot

Differential Revision: D8824634

fbshipit-source-id: 6765472aeeacb55c68b058f5dcc128f6b400bc95

Summary:
GLOG has `-logbuflevel` option that allows a user to specify the level above which none of the logs should be buffered. This is helpful as we can configure it such that `INFO` and all verbose logs are buffered before being output, but all logs above `INFO` should be flushed synchronously. This will ensure that all logs above a certain level are printed before any sort of crash.

This diff allows a user to specify a config `sync_level`. The value for this can be any `LogLevel`. Example config:

  .=WARN,akkio.cli=INFO; default:async=true,sync_level=WARN

The default value for GLOG's -logbuflevel is `0` (`INFO`).
To match GLOG's behavior, this diff sets the following as defaults:

  async=true,sync_level=WARN

Reviewed By: simpkins

Differential Revision: D8867555

fbshipit-source-id: 7ec30dfb41b2f3cd3568d70304db7a9fcf668779

Summary: Update default log level for Folly's logging to match that of Google's logging. This will make it easier to migrate between the two.

Reviewed By: simpkins

Differential Revision: D8941725

fbshipit-source-id: 14ed352d9a012f2604ff4329cc7cd038b2c0ee26

Summary: These headers don't include everything they use so things build now because of rando include orders and transitive inclusion. Breaks when attempting to build with clang modules.

Reviewed By: shixiao

Differential Revision: D8954753

fbshipit-source-id: d222370f17594f5c6aeccd21cbfd61bd8102245a

Summary:
Add resource monitor object to fbzmq library to monitor CPU and memory. User can use
the object to query RSS memory, cpu usage, and optionally call API to monitor memory periodicially
 and crash when reaches beyond a specified threshold limit.

Reviewed By: cenzhao

Differential Revision: D8873504

fbshipit-source-id: a445fdd580da82c55fba09c43f46f60bb9f1149a

Summary: Destructor unlinks and reclaims nodes immediately without checking hazard pointers.

Reviewed By: djwatson

Differential Revision: D8864161

fbshipit-source-id: 270df5e6b3ef8bc33934b6d55df465309f1068bd

Summary: [Folly] Generic conversion from `Range` in cases like `std::string_view` which are constructible with `Iter, size_type` instead of `Iter, Iter`.

Reviewed By: vitaut

Differential Revision: D8907212

fbshipit-source-id: 6f93581b7185d4d10925aa57175f130dff2576e3

Summary:
[Folly] Use traits in `Range` conversion functions.

Dependent code requires this for msvc2015.

Reviewed By: vitaut

Differential Revision: D8929559

fbshipit-source-id: dbf4afbebdf92ee4eb46067ff443980823cd771d

Summary: HHWheelTimer::Callback is frequently used as a base class for callback objects, while context_ is a commonly desired member name in other classes that also serve as base classes for HHWheelTimer::Callback derived classes. Renaming in HHWheelTimer::Callback to free up availability of context_.

Reviewed By: yfeldblum

Differential Revision: D8937020

fbshipit-source-id: 8a4612bc57f28673762604cc118a91a347e5972d

Summary:
This attempted to provide a deep copy guard for folly request context.

Per brainstorming (see task), we don't think that deep copying all metadata has legitimate use cases. And in fact, this has no usage in our codebase currently. Because it default to reset (when createChild is not overriden), the behaviour is also very confusing.

Guards's goal is usually to copy 1 metadata. The solution for that is to provide a shallow copy guard. Something that I will do on top of this revert.
I'll wait for both changes to be discussed and accepted before landing this one.

Reviewed By: yfeldblum, LeeHowes

Differential Revision: D8906912

fbshipit-source-id: e8b9eed04cbe539009037ff75d51e28941502d88

Summary:
My guess is that if we allow to set data in the default context, we also expect set/unset to work.
It currently doesn't. This fixes it (at least, the test repro passes), but not sure it's the right fix.

Reviewed By: djwatson

Differential Revision: D8910506

fbshipit-source-id: cedf1dd0ee91761d210137949da7477ed69fce31

Summary: [Folly] Comments to document explicit conversions from `Range`.

Reviewed By: terrelln

Differential Revision: D8921990

fbshipit-source-id: 0728e0096738f9a86eecfaa5b05d4dfbcb0533b6

Summary: [Folly] Cut non-`const` conversion overloads from `Range`, for both `operator T` and `to<T>`: let them be `const` member functions so that the converted-to object cannot update `Range` internal state.

Reviewed By: terrelln, vitaut

Differential Revision: D8921428

fbshipit-source-id: eefc14b5fe2033cac43ebc274b27bdea95388488

Summary:
lastOccupiedChunks has UB with an empty container, because
the end() iterator itemPtr_ is null.

And with a single chunk, we must enter the iteration loop.

Reviewed By: nbronson

Differential Revision: D8897447

fbshipit-source-id: 7e7fd06ec7a588236eebf28f43af9ef4ab2d39cd

Summary: Fix threadlocal_detail::ElementWrapper::dispose crash due array to reallocation

Reviewed By: yfeldblum, djwatson

Differential Revision: D8868394

fbshipit-source-id: dc0c91250f2ffbcba7ac4f0bcf0d048e7785d65f

Summary: ThreadPoolExecutor could dynamically adjust number of threads according to workload. Add numActiveThreads() so we can check how many active threads are actually there, while numThreads() returns the upper bound of threads.

Reviewed By: djwatson

Differential Revision: D8683795

fbshipit-source-id: 09f3b4ee8570e2f2f9f97e939061693f3e0639af

Summary:
Add unlink_and_reclaim member function to hazptr_obj_base_linked, as an alternative to unlink() that reclaims the object if its link count is zero without checking hazard pointers.
It is useful in destructors of data structures when it is guaranteed that objects are not protected by hazard pointers (e,.g., destructor of ConcurrentHashMap).

Reviewed By: yfeldblum

Differential Revision: D8864019

fbshipit-source-id: 618eeded45a1f8b9503569d1ceca9994ca6e317f

Summary:
Eliminate while loop behavior in DeterministicSchedule::join

Depends on D8789304

Reviewed By: djwatson

Differential Revision: D8840276

fbshipit-source-id: f0b0db60f7bec344d021a49cec408a2604d4a1c8

Summary: Eliminate spinlock behavior from DeterministicMutex::lock by descheduling threads waiting to acquire the mutex, and placing the thread local semaphore in a waitqueue for the mutex. The unlocking thread reschedules a single waiting thread if the workqueue is non empty.

Reviewed By: djwatson

Differential Revision: D8789304

fbshipit-source-id: 8ffe3e289c9abfe7515b678ff98f0cefef2461c0

Summary:
For use in tests where the executor has a nontrivial lifetime but any
queued jobs should be completed, have ManualExecutor drain itself
before it's destroyed.

Reviewed By: yfeldblum

Differential Revision: D8845457

fbshipit-source-id: 7c2aa65aa27a7850ff73a93cfbe34c2248b62d26

Summary:
Change the write acquire interface to only acquire write locks on non-const
`Synchronized` instances.  This reflects the intention of mutation associated
with a write lock.

Reviewed By: yfeldblum

Differential Revision: D8851208

fbshipit-source-id: 5be9d2e4a38d25632430a9b6c981b6e7f8412daa

Summary: Fix broken opt build due to "error: unused variable 'rv'"

Reviewed By: yfeldblum

Differential Revision: D8883701

fbshipit-source-id: 2a832cfea0bd9cbca63a8d5c2c8d7127593728af

Summary: Users acquiring upgrade locks should only be allowed to lock the synchronized object when it is non-const.  Because an upgrade locks are permitted to transition to write locks when mutation is required.  At which point non-const access is often required on the Synchronized object.

Reviewed By: yfeldblum

Differential Revision: D8654360

fbshipit-source-id: c2a6574bd880db0d8e4c90166e288f5b83542ad6

Summary:
F14 currently has numerous places where folly::assume is used to
help optimization on GCC < 6.  These are all things the optimizer should
be able to deduce itself, so it would be nice to eventually remove them.
This diff marks them with TODO(T31574848), as well as removing two
occurrences in F14Table that duplicated an assume in F14Policy.

Reviewed By: yfeldblum

Differential Revision: D8849832

fbshipit-source-id: e88143b4d29f1a633b51467206c6fb6afd1cd296

Summary: Remove the ' ' prior to : in folly::json's pretty output - this improves consistency with other JSON formatters.

Reviewed By: yfeldblum, luciang

Differential Revision: D8843977

fbshipit-source-id: 1d5c84d7d3806ad8752b619ffe23101f7f103683

Summary:
- Add cleanup of remaining items, if any, at destruction.
- Add test.

Reviewed By: davidtgoldblatt

Differential Revision: D8860966

fbshipit-source-id: e3ab2e6ff31e08d91aa20c8c058471823c722a38

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