Summary:
This introduces `__folly_memcpy`, which is an implementation of `memcpy` that uses prefetch to speed up cold copies (data absent from L1) and uses overlapping copies to avoid as much branching as possible to speed up hot copies (data present in L1).

A description of the core ideas for this memcpy is in the file comment at the top of folly_memcpy.S.

`__folly_memcpy` *does* act as a `memmove`, although it isn't optimized for that purpose for copies of 257 or more bytes. This masks some undefined behavior bugs when code calls `memcpy` on an overlapping region of data. `perf` samples will show when `memmove` is called by `__folly_memcpy`, which will help identify these undefined behavior bugs for copies of 257 bytes or more.

Reviewed By: yfeldblum

Differential Revision: D23629205

fbshipit-source-id: 61ed66122cc8edf33154ea6e8b87f4223c0ffcc0

Summary:
Add missing hazard pointer protection of the new node inserted by a successful try_emplace.

Add test that breaks without this fix.

Reviewed By: yfeldblum

Differential Revision: D28361211

fbshipit-source-id: 963527a9c6b24b0cb569d5b49da9ef9a0e8b58cd

Summary:
There are lint rules that should discourage code from doing non-trivial
things as part of static initialization, e.g., calling a complex
constructor.

That said, probably someone somewhere in fbcode does that so I got
wrapped around the axel trying to change this code to prevent such a
race with ConstructorCallback.

The concern was that if someone created a Foo()
pre-main() there might be an initialization race for
ConstructorCallback<Foo>::nConstructorCallbacks_ and if we lost that race,
we would issue callbacks on garbage data.

BUT - apparently the C++ standard initialization requires that all static
zero values are initialized before more complex initilization, so this
can't happen (assuming the compiler correctly implements the spec).
So this code change is just to add a commment with the information so
no one else goes chasing down this (false) rat hole...

Differential Revision: D27969959

fbshipit-source-id: c135d1bb235d652d11e0541cc09a10a1bad1ce87

Summary: title

Reviewed By: yfeldblum

Differential Revision: D28345979

fbshipit-source-id: ea55db34e19d3881c65559172d4fc9df4808fdad

Summary:
TSAN catches this as a data race, though it's fairly benign. In the
assert we read non-atomic `state` without holding the lock. As a fix, acquire
the lock in the assert. The assert is skipped anyway in opt builds.

Reviewed By: yfeldblum

Differential Revision: D28302491

fbshipit-source-id: b92ca9f3d321d34301d96e59fab363d999bddb30

Summary: It cannot yet be assumed in all places.

Reviewed By: MartinSherburn

Differential Revision: D28325332

fbshipit-source-id: b48a1f9d83c2171ef3912b33c55e9cf8fe294c32

Summary: D26331579 (https://github.com/facebook/folly/commit/aa7f74aaf68ab0a7eb834f49a864c277dbe5fe09) was the offending diff that caused an insta crash on Messenger Android and Instagram Android. Backing out for now.

Reviewed By: JunqiWang

Differential Revision: D28308563

fbshipit-source-id: 87a547d9ba7cb3b33a4ddee9e273943f8379d990

Summary: Also backed out D28276400 (https://github.com/facebook/folly/commit/b24643035fb8778b87feefdb3a365c06583ce53f) because it has a dependency to D26331579 (https://github.com/facebook/folly/commit/aa7f74aaf68ab0a7eb834f49a864c277dbe5fe09)

Reviewed By: lhuang04, JunqiWang

Differential Revision: D28309181

fbshipit-source-id: 0e04e00c59d497290aa0067177a51fe1cfc5e144

Summary: No such function exists.

Reviewed By: luciang

Differential Revision: D28276400

fbshipit-source-id: 57d9ede6df0570f2cc8b0a0b5bd77f2cb6be9fd7

Summary: Adds a policy around whether token-bucket is used only non-concurrently, in which case compare-exchanges can be optimized to stores.

Differential Revision: D28230482

fbshipit-source-id: 2c00797dc943e9ea8985737a8c7dda059a195cfe

Summary:
Reimplement `folly::exception_wrapper` thrown variant not to need to cache any pointers and rather to access the exception object and runtime type, and to perform runtime upcasting, via the platform runtime.

This both simplifies and extends the capability of the thrown variant.

Reviewed By: luciang

Differential Revision: D26331579

fbshipit-source-id: a6fe0f10434956efa5ba4b4bcd1bd3a1b48466a4

Summary:
Starting with C++11, implicit generation of the copy constructor is declared as deprecated.
> § D.2 Implicit declaration of copy functions [depr.impldec]
> The implicit definition of a copy constructor as defaulted is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. The implicit definition of a copy assignment operator as defaulted is deprecated if the class has a user-declared copy constructor or a user-declared destructor (15.4, 15.8). In a future revision of this International Standard, these implicit definitions could become deleted (11.4).

Clang-12 produces diagnostics for these cases, which is turned into errors for folly:
```
folly/test/AtomicHashMapTest.cpp:330:12: error: definition of implicit copy constructor for 'Integer' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
  Integer& operator=(const Integer& a) {
           ^
```

Reviewed By: yfeldblum

Differential Revision: D28239770

fbshipit-source-id: a28d19ec774264944b750aa267e93d4fa6d1744e

Summary: The atomic location is not used to order memory.

Reviewed By: jbeshay

Differential Revision: D28229348

fbshipit-source-id: c6206d4b72025e1f7f68adc822e9ae4ed13bd8b4

Summary: Items which are subject to policy: align, atom, and clock.

Differential Revision: D28229049

fbshipit-source-id: e65512265abaa8b777f95cf3233d96a70df73c5f

Summary:
Adding new `parseTo` overload for `std::string_view`, and related tests.

Facilitates migration from `folly::StringPiece` to `std::string_view` by supporting:

```lang=c++
splitTo<string_view>(...)
```

Reviewed By: yfeldblum

Differential Revision: D27971000

fbshipit-source-id: 732f968eb6797447ae12bdc70dbb82d5fc6a8a33

Summary: If inlining and constant folding can determine that the buffer is larger than the `to_ascii_size_max` constant, then there is no need to call the `to_ascii_size` function an extra time.

Differential Revision: D27986105

fbshipit-source-id: d088001a7b3632dabb794c86dafdaa93dd0c1348

Summary: In case some `<cxxabi.h>` actually defines it rather than keeping it defined in some unincluded helper.

Reviewed By: luciang

Differential Revision: D28239978

fbshipit-source-id: 4d824892966de4b9f8de775d947f5d7d749a02bb

Summary: It was needed only to call into legacy APIs which are themselves unneeded.

Differential Revision: D28227187

fbshipit-source-id: 4248a7f39c7bea3224f4c2eb73e4815db71c9584

Summary:
Problem:
- Some call sites use `folly::make_unique` whose functionality exists in
  the standard library now. In the future, `folly::make_unique` may be
  removed.

Solution:
- Replace call sites to use `std::make_unique`.

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

Differential Revision: D28235226

Pulled By: yfeldblum

fbshipit-source-id: 2dd85f4d234881d682adaf4b5bbe947f56edaa4e

Summary:
The macro `_LIBCXXABI_HIDDEN` is seeminly unavailable on FreeBSD so avoid its use in the exception-ptr abi accessors.

Fixes: https://github.com/facebook/folly/issues/1570.

Reviewed By: luciang

Differential Revision: D28217011

fbshipit-source-id: c745ae468c840c33df921c68fb06759c078b6df0

Summary: Add re2 as a dependency on getpdeps

Reviewed By: funrollloops

Differential Revision: D28208007

fbshipit-source-id: 7e6ab7a0a01f4b2fe264780e09befc34a030a896

Summary:
To remove OpenSSL dependencies from some of our public interfaces, we need to
make `AsyncTransportCertificate` more implementation-agnostic. To start, we can
create an `OpenSSLTransportCertificate` that will have the `getX509()` method
instead of the `AsyncTransportCertificate`.

I start here by making `OpenSSLTransportCertificate` a dummy class, then I'll
update all our callsites to ensure that `getX509()` is only called on instances
of this class. After that, I can move `getX509()` exclusively to
`OpenSSLTransportCertificate`.

This means that in the future interfaces can use `AsyncTransportCertificate`
without depending on OpenSSL.

Reviewed By: yfeldblum, mingtaoy

Differential Revision: D26583479

fbshipit-source-id: 664e697a32fce61d22ee9842f998c4de1182924c

Summary: The actual shim type may sometimes not be linkable. So fake it - as long as the vtable is the same, it should not make a difference.

Reviewed By: luciang

Differential Revision: D28216291

fbshipit-source-id: 8c493a207cfb5414684147ddb850835bc0965bc5

Summary:
This applies the formatting changes from black v21.4b2 to all covered
projects in fbsource. Most changes are to single line docstrings, as black
will now remove leading and trailing whitespace to match PEP8. Any other
formatting changes are likely due to files that landed without formatting,
or files that previously triggered errors in black.

Any changes to code should be AST identical. Any test failures are likely
due to bad tests, or testing against the output of pyfmt.

Reviewed By: thatch

Differential Revision: D28204910

fbshipit-source-id: 804725bcd14f763e90c5ddff1d0418117c15809a

Summary:
Rather than specializing standard library numeric traits for `signed __int128` and `unsigned __int128`, bring these traits into folly and choose them where needed.

Note that it is undefined behavior to specialize the standard traits types.

Reviewed By: ericniebler

Differential Revision: D26506904

fbshipit-source-id: 0f7b0fa445c2713961b345b453fef8ff58032ee5

Summary: GCC seems to be generating incorrect code for some mix of co_invoke and start/startInline. This workaround makes coro tests pass.

Reviewed By: yfeldblum

Differential Revision: D28174118

fbshipit-source-id: b8178d7711ed5619a37c169f8f18dd125bf08f0b

Summary:
Replace DCHECK(tagged_empty()) with a warning.

The rationale is that the DCHECK was intended to help higher level users detect memory leaks, but since the DCHECK fails at domain destruction, the stack trace is not really helpful to users. By changing it to a warning, at least the user gets a hint that there may be a leak of object(s) that use hazptr_obj_cohort (e.g., ConcurrentHashMap, RequestContext).

Reviewed By: yfeldblum

Differential Revision: D28145864

fbshipit-source-id: 8a79e25efd21f0b1d713202f2fe8954c17a7d4de

Summary: Fix for the proxygen fuzz [build error]( https://oss-fuzz-build-logs.storage.googleapis.com/log-e58a42bb-98c0-4643-b842-b06f708eba12.txt) introduced by D27384053 (https://github.com/facebook/folly/commit/cdf0badc831c3aed7a740185d23728f779be8ba7)

Reviewed By: yfeldblum, lnicco

Differential Revision: D28154352

fbshipit-source-id: 6d98d9a3c9064de8f70506425dd790aa0cc3d9a6

Summary:
Suppose we have this:

```
void myBenchmark() {
    do_setup();
    do_processing();
}
```

Maybe we want to benchmark both including and excluding the setup.  Today, we have some options:

One possibility:
```
void myBenchmarkIncludeSetup() {
    do_setup();
    do_processing();
}

void myBenchmarkExcludeSetup() {
    BENCHMARK_SUSPEND {
       do_setup();
    }
    do_processing();
}
```

Another possibility -- but this is pretty verbose:

```
void myBenchmark(bool exclude_setup) {
    BenchmarkSuspender bs;
    bs.dismiss()

    if(exclude_setup) bs.rehire();
    do_setup();
    if(exclude_setup) bs.dismiss();

    do_processing();
}
```

We can simplify if we no longer require that BenchmarkSuspenders begin life as "hired".

After this diff, we can instead do this.  I think it reads better:
```
void myBenchmark(bool exclude_setup) {
    BenchmarkSuspender bs{BenchmarkSuspender::Dismissed};

    if(exclude_setup) bs.rehire();
    do_setup();
    if(exclude_setup) bs.dismiss();

    do_processing();
}
```

Reviewed By: yfeldblum, ot, luciang

Differential Revision: D28151318

fbshipit-source-id: bca5a41158430844748a812bbe30173adbad5307

Summary: Ideal for dependent return types to be calculated in the template param list rather since the putting them in the leading or trailing return type slot makes the function name opaque to demangling.

Reviewed By: Orvid

Differential Revision: D28140885

fbshipit-source-id: 0f9bc182f12a6383205863ce9a79b01961d644a6

Summary:
Currently to_ascii_port_clzll() in ToAscii.h always returns 0 in x86. This switches to __builtin_clzll() backed by a polyfill.

Closes https://github.com/facebook/folly/issues/1566.

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

Reviewed By: luciang

Differential Revision: D28162903

Pulled By: yfeldblum

fbshipit-source-id: 1872cda7aa155b84086bd15ad6cd40475eeb0ac4

Summary: Best to use C++ syntax `thread_local` instead since it is language-native and cross-platform.

Reviewed By: Orvid

Differential Revision: D27671626

fbshipit-source-id: 8ef0c487bfa20ab323067c05862998df25d2a53b

Summary: The port is not accessed in such a state, but nevertheless zero it.

Differential Revision: D28155314

fbshipit-source-id: 0ee6a617be5de66d1e068c242d52423adb31f486

Differential Revision: D28163554

fbshipit-source-id: 2167a39e88f7aa6053dea5119a30947d2f3304f3

Summary: Add support for AsyncUDPSocket SO_BINDTODEVICE

Reviewed By: danobi

Differential Revision: D28100917

fbshipit-source-id: bcc66d943342cbd40b634ef095eccf3e599fcb65

Summary: Revise all overloads of `folly::exceptionStr` in terms of `type_info_of`, `exception_ptr_get_type`, and `exception_ptr_get_object`. No longer rely on `catch_exception` and no longer have inline preprocessor conditionals.

Reviewed By: Orvid, luciang

Differential Revision: D26333081

fbshipit-source-id: 318ce83b9f15a12d5a33f528134e6fb38bb78a62

Summary: The table is large while the array is small.

Reviewed By: luciang

Differential Revision: D27986020

fbshipit-source-id: b6896514408758c592e2b74d801e38f217163f61

Summary:
Introduce functions `exception_ptr_get_type`, `exception_ptr_get_object` for inspecting and upcasting the content of `std::exception_ptr`. Since these facilities are not exposed in any standard way, reach into the platform abi/runtime to implement them.

Includes implementations for these platforms:
* libstdc++
* libc++
* win32

Reviewed By: mzlee, luciang

Differential Revision: D26306199

fbshipit-source-id: 3b655476b69f4456f4e4f88135fbba70a8c4a2a6

Reviewed By: Orvid

Differential Revision: D27671636

fbshipit-source-id: 82cab152ecb606235ee66c026ecafecfe52a88a5

Summary:
This correctly walks the async stack traces. Previously, we were not following the async stack root
from the last async stack frame.

High level stack walking strategy is as follows:
1) Start walking the normal stack up to the first normal stack frame holding the first async stack root
2) Walk the async stack frame chain from the provided async stack root
3) When we reach the end of the current async stack frame chain, check if the last async stack frame references an async stack root R1.
   If there is one, use R1 to find the start of the next normal stack frame when walking the normal stack frame.
4) If that async stack root R1 has a next async stack root R2, the normal stack frame walk should end at the normal stack frame
   holding the next async stack root R2. Otherwise the normal stack frame walk should continue all the way until it hits nullptr.
5) The next async stack walk should begin at the top async frame referenced by the next async stack root R2.
6) Repeat until we've reached the end of both the normal and async stack frame chains.

Reviewed By: andriigrynenko

Differential Revision: D28102128

fbshipit-source-id: c412a2a253720867c257d5cbaa9a6b22e96154f2