Summary:
Since 60da8ef5, typed tests have been moved to a separate unit (`AsyncBaseTestLib`), which is not the part of `folly` or `folly_test_support`.

This commit adds `AsyncBaseTestLib` to `async_io_test`'s sources.

Alternatively, the test lib could be added to `folly_test_support` with an additional check on `LIBAIO_FOUND`, but `AsyncBaseTestLib` has a specific `TemporaryFile` implementation that conflicts with the one in `experimental/TestUtil.h`.
Pull Request resolved: https://github.com/facebook/folly/pull/1313

Reviewed By: simpkins

Differential Revision: D19648091

Pulled By: yfeldblum

fbshipit-source-id: 27881b464dc3c84aa20ffee1ffd3320e0a67eb27

Summary: [Folly] Use `cacheline_aligned` in small-locks benchmark.

Reviewed By: aary

Differential Revision: D19614282

fbshipit-source-id: d5ec3e9d970654cc532a880de951ac20c898c90a

Summary: std::memcmp is only meaningful for trivially-copyable objects with no padding. Before this diff, `func` is empty class and the check can fail since padding byte is undetermined.

Reviewed By: yfeldblum

Differential Revision: D19460552

fbshipit-source-id: 1b98876a12053c1e7d342e4d8a5fcb25d94f77f3

Summary:
The AsyncGenerator was not clearing its Executor::KeepAlive when it ran to completion.

This meant that when you call `blockingWait(gen.next())` and this would result in the end-of-stream (error or done) then `blockingWait()` would never return because the destructor of the local executor created in the call was blocked waiting for all KeepAlive instances to be destroyed - but this would not happen until the AsyncGenerator was destroyed.

AsyncGenerator now clears the caller context (which includes the KeepAlive) when the coroutine runs to completion.

Reviewed By: kirkshoop

Differential Revision: D19625741

fbshipit-source-id: f3254181af14828b32bfa8f7ef5d400d53c04efa

Summary:
[Folly] `reentrant_allocator`, a multi-thread-safe and async-signal-safe allocator.

Based on `mmap` for dynamic allocation. While, technically, `mmap` is not documented to be async-signal-safe, in practice it is so at least on Linux. Take advantage.

Details:
* Large allocations are handled directly by `mmap` and deallocations by `munmap`, where large-size is 2^12 (1 page) by default; they are not tracked; they are aligned only to page boundaries.
* Small allocations are handled by an `mmap`-backed refcounted arena list. Arena sections are block-size bytes less overhead by default, where block-size is 2^16 (16 pages) by default; they are allocated on demand; and they are linked together to allow for `munmap` when the allocator refcounted arena list is destroyed.

Reviewed By: nbronson, luciang

Differential Revision: D19222635

fbshipit-source-id: adf30580c1bf3dd7f8dab13b1d4ac1e10b2f5c52

Summary:
clang has the warning `-Wnullability-extension` to avoid unportable code. Folly correctly handles it, so let's
ignore the warning if it is set.

(Note: this ignores all push blocking failures!)

Reviewed By: stepancheg

Differential Revision: D19580470

fbshipit-source-id: 59ddb5377a98d907a62df5d480b1ea0a65645a6b

Summary:
MSVC seems to have a bug when handling private classes that
are both part of the inheritence hierarchy (private superclass of a
superclass) and available as a template parameter, incorrectly claiming
that the class is inaccessible due to private inheritance. This diff
works around the issue. It also adds an explicit case to avoid a narrowing
warning generated by MSVC.

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum, mjoras

Differential Revision: D19561643

fbshipit-source-id: 494d1611ce662a0eb6c441c64479d3c5d2bbd5b6

Summary: It's unsafe to destroy the object before keepAlive reaches 0. We can still skip running the scheduled functions if those are unsafe to run.

Reviewed By: nanshu

Differential Revision: D19605152

fbshipit-source-id: b99c28dc65da2a5621ce5260491c13754fca03ad

Summary: Produce a -Wdeprecated-declarations warning in code that uses the old SYNCHRONIZED macros.

Reviewed By: yfeldblum

Differential Revision: D19567088

fbshipit-source-id: b0637c06cbd125d09e1b39eec1e82a71ddca2324

Summary:
`-Wrange-loop-analysis` complains about the unnecessary copy.

```
In file included from servicerouter/common/InstanceCount.h:9:
folly/experimental/SingletonRelaxedCounter.h:77:21: error: loop variable 'kvp' of type 'const std::pair<std::atomic<long> *const, unsigned long>' creates a copy from type 'const std::pair<std::atomic<long> *const
, unsigned long>' [-Werror,-Wrange-loop-analysis]
    for (auto const kvp : tracking->locals) {

...

folly/experimental/SingletonRelaxedCounter.h:77:10: note: use reference type 'const std::pair<std::atomic<long> *const, unsigned long> &' to prevent copying
    for (auto const kvp : tracking->locals) {
```

Reviewed By: stepancheg

Differential Revision: D19554423

fbshipit-source-id: 742dd4e7d144dd2dd0c888236b85f222373e9e54

Reviewed By: yfeldblum

Differential Revision: D19579433

fbshipit-source-id: ab63d21e679a8f73547d27200e738558fc69a15b

Summary:
`folly::to<uint32_t>()` and `folly::to<uint64_t>()` were silently failing
and truncating the input when negative values were passed:

```
int8_t x = -1;
folly::to<uint8_t>(x); // THROWS

int16_t x = -1;
folly::to<uint16_t>(x); // THROWS
```

all throw folly::ConversionError, but

```
int32_t x = -1;
folly::to<uint32_t>(x); // DOES NOT THROW

int64_t x = -1;
folly::to<uint64_t>(x); // DOES NOT THROW
```

The actual bug is in `less_than<>()`, from Traits.h, which in these cases relies that `(uint32)0 <= std::numeric_limits<int32_t>::min()`, which doesn't hold according to the standard.

The fixes in this diff are:

- Fix `less_than<>()` to properly support signed to unsigned conversions
- Fix `less_than<>()` to properly support unsigned to signed conversions
- Fix `greater_than<>()` to properly support signed to unsigned conversions
- Fix `greater_than<>()` to properly support unsigned to signed conversions
- Add unit tests to cover all these cases.

Reviewed By: yfeldblum

Differential Revision: D19511557

fbshipit-source-id: 48649dfcdadeaa652c8f57f7b11481de44a88927

Summary:
[Folly] Suppress `header-hygiene` warnings.

(Note: this ignores all push blocking failures!)

Differential Revision: D19529773

fbshipit-source-id: a4e0f49010ad17b72a55cd462a7a7c3e43b72c2a

Summary: Add support for sendmmsg GSO option

Reviewed By: yfeldblum

Differential Revision: D19521628

fbshipit-source-id: 5611074a5cfb626ce42ffe99d1de78b8e57238c2

Summary:
Extra `;`, shadowed declarations and unitialised variables
were causing warnings to callers.

Reviewed By: stepancheg

Differential Revision: D19537831

fbshipit-source-id: 259cf9974592191c84d424bbdf3bd1c68425a76c

Summary: Remove the shared CheckAtomic cmake module out of the shared dir and back to the projects that need it.

Reviewed By: lukaspiatkowski

Differential Revision: D19553656

fbshipit-source-id: 5e89b5b9448ef6d6c57ef904a652e9f9a1d5dbb3

Summary: Handle __clang__ warnings under Windows

Differential Revision: D19529853

fbshipit-source-id: 936f4acaaf0f601fc09e5e7de447b9c9b4c34151

Summary:
release() returns ptr contained and thus we never actually call the destructor :|

.reset() is what we wanted, call the destructor NOW.

Reviewed By: yfeldblum

Differential Revision: D19548008

fbshipit-source-id: be904a7b5fb84aae5deef408e9d8e05fcd930a4c

Differential Revision: D19539438

fbshipit-source-id: 88c536a72a9b54d36ead2215d935745710d1d3db

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

The current documentation for the various Folly::Rcu retire functions is lacking, so this commit adds comment headers.

Reviewed By: magedm

Differential Revision: D18631443

fbshipit-source-id: 690d3c6f0d7c3142d74c97b3388fd973ca2abaac

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

The current documentation for Folly::rcu_reader and Foly::rcu_reader_domain is lacking, so this commit adds comment headers.

Reviewed By: ot, magedm

Differential Revision: D18620267

fbshipit-source-id: 98d26aa2f54fccf85de1fc5fda99a1843739bee0

Update the CheckAtomic CMake module to check for __atomic_fetch_add_4 instead of __atomic_is_lock_free

Summary:
When building with clang, the build fails with:

```
-- Looking for __atomic_is_lock_free in atomic
-- Looking for __atomic_is_lock_free in atomic - not found
CMake Error at cmake/CheckAtomic.cmake:90 (message):
  Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
  CMakeLists.txt:75 (include)
```

And the error is:

```
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:7:3: error: conflicting types for '__atomic_is_lock_free'
  CHECK_FUNCTION_EXISTS(void);
  ^
<command line>:1:31: note: expanded from here
#define CHECK_FUNCTION_EXISTS __atomic_is_lock_free
                              ^
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:7:3: note: '__atomic_is_lock_free' is a builtin with type 'int (unsigned long, const volatile void *)'
<command line>:1:31: note: expanded from here
#define CHECK_FUNCTION_EXISTS __atomic_is_lock_free
                              ^
/usr/share/cmake-3.10/Modules/CheckFunctionExists.c:17:25: error: too few arguments to function call, expected 2, have 0
  CHECK_FUNCTION_EXISTS();
  ~~~~~~~~~~~~~~~~~~~~~ ^
```

LLVM's CheckAtomic (https://fburl.com/bk14shjt) uses `__atomic_fetch_add_4` so I'm modifying the configs to use it as well to check for the existence of the library.

Reviewed By: yfeldblum

Differential Revision: D19497168

fbshipit-source-id: 64f77487efd16dba49055f6c4cb1cdd0fc4ae6da

Summary: Rename hazptr obj batch to obj cohort, a more accurate description.

Reviewed By: davidtgoldblatt

Differential Revision: D19518771

fbshipit-source-id: f50a8a481f260dde4fce10fb9664d4f86c263b60

Summary:
F14MapTest's continuousCapacitySmall test implicitly assumed
that folly::F14FastMap<std::size_t, std::string> uses the vector storage
policy, but this is not the case if std::string is 8 bytes.  Remove the
assumption.

Differential Revision: D19431446

fbshipit-source-id: 6e6f0cbe7f57b23b2df38c87bb36a6532ab97a14

Differential Revision:
D19384064

Original commit changeset: a2a6397b94aa

fbshipit-source-id: e8ba1e8f6b3c3d3840a912e4c094b570b23ccbcf

Differential Revision:
D19437477

Original commit changeset: 1755a71678cb

fbshipit-source-id: 7fce386def631d1cf217de528b15d37aee5e921b

Differential Revision:
D19444082

Original commit changeset: 5a5524046090

fbshipit-source-id: ecb9b9048af9c00c951cb6e540433b5a3cecaf71

Differential Revision:
D19438098

Original commit changeset: 12f1d5c60067

fbshipit-source-id: de234114216abf243256fa7ac8c1faf7b0b4bb0b

Summary:
The default allocator for `new` does not apparently respect the extended alignment requirement for `hasptr_rec<Atom>`. We use folly's AlignedSysAllocator for these cases, which will then pass UBSan checks for alignment.

```
xplat/folly/synchronization/HazptrDomain.h:572:20: runtime error: constructor call on misaligned address 0x60c0000004c0 for type 'hazptr_rec<atomic>', which requires 128 byte alignment
0x60c0000004c0: note: pointer points here
 02 00 00 7f  be be be be be be be be  be be be be be be be be  be be be be be be be be  be be be be
              ^
    #0 0x77949e in folly::hazptr_domain<std::atomic>::acquire_new_hprec() xplat/folly/synchronization/HazptrDomain.h:572:16
    #1 0x7791cc in folly::hazptr_domain<std::atomic>::hprec_acquire() xplat/folly/synchronization/HazptrDomain.h:227:35
    #2 0x766a7f in folly::hazptr_holder<std::atomic>::hazptr_holder(folly::hazptr_domain<std::atomic>&) xplat/folly/synchronization/HazptrHolder.h:71:21
    #3 0x766a7f in void folly::UnboundedQueue<folly::CPUThreadPoolExecutor::CPUTask, false, false, false, 6ul, 7ul, std::atomic>::enqueueImpl<folly::CPUThreadPoolExecutor::CPUTask>(folly::CPUThreadPoolExecutor::CPUTask&&) xplat/folly/concurrency/UnboundedQueue.h:374
```

Reviewed By: magedm

Differential Revision: D19237973

fbshipit-source-id: 0edea12bb3f028d21830689d52f7e0290d187ff9

Summary:
Until C++17 types with extended alignment need special handling
in eg. std::vector and also std::unique_ptr. CPUThreadPoolExecutor has a
default queue that requires extended alignment, but also allows the user
to provide their own blocking queue. To handle this we move the private
member to a shared_ptr which supported type erased destructors, and then
use allocate_shared for the default queue type with a custom allocator
that will satisfy alignment constraints.

```
.../unique_ptr.h:825:34: runtime error: constructor call on misaligned address 0x613000000040 for type 'folly::UnboundedBlockingQueue<folly::CPUThreadPoolExecutor::CPUTask>', which requires 128 byte alignment
0x613000000040: note: pointer points here
 02 00 00 1c  be be be be be be be be  be be be be be be be be  be be be be be be be be  be be be be
              ^
    #0 0x75b35e in std::_MakeUniq<folly::UnboundedBlockingQueue<folly::CPUThreadPoolExecutor::CPUTask> >::__single_object std::make_unique<folly::UnboundedBlockingQueue<folly::CPUThreadPoolExecutor::CPUTask> >() .../unique_ptr.h:825:30
    #1 0x75602f in folly::CPUThreadPoolExecutor::CPUThreadPoolExecutor(unsigned long, std::shared_ptr<folly::ThreadFactory>) xplat/folly/executors/CPUThreadPoolExecutor.cpp:66:18
    #2 0x756c6c in folly::CPUThreadPoolExecutor::CPUThreadPoolExecutor(unsigned long) xplat/folly/executors/CPUThreadPoolExecutor.cpp:84:7
```

Differential Revision: D19237477

fbshipit-source-id: c88b26e2ca17e168f124ba27c0989f787b1ce4fd

Summary: `-Wredundant-parens` complains about those.

Reviewed By: luciang

Differential Revision: D19347715

fbshipit-source-id: 7460ff1ee675774e8811db95d12ac02ce7e924ea

Reviewed By: yfeldblum

Differential Revision: D19331966

fbshipit-source-id: ad369c51eb1253faf293fc37457d2c8122e3d227

Summary:
Range lists are contained in a separate object file section called .debug_ranges. A range list is
indicated by a DW_AT_ranges attribute whose value is represented as an offset from the
beginning of the .debug_ranges section to the beginning of the range list.

Each entry in a range list is either:
- a range list entry,
- a base address selection entry, or
- an end of list entry.

Reviewed By: luciang

Differential Revision: D19438098

fbshipit-source-id: 12f1d5c60067b0674c44f35ef2731781eb93f1d5

Summary:
Here is an example for class inline member function declared and defined in the same file:

```
Definition:
0x00004c0a:           DW_TAG_subprogram [55] *
                        DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x00177124] = "_ZNK5folly10symbolizer4test24ClassWithInlineFunctions9inlineBarERNS0_10FrameArrayILm100EEE")
                        DW_AT_name [DW_FORM_strp] ( .debug_str[0x00089a73] = "inlineBar")
                        DW_AT_decl_file [DW_FORM_data1] (0x1a)
                        DW_AT_decl_line [DW_FORM_data1] (0xa5)
                        DW_AT_declaration [DW_FORM_flag_present]  (true)
                        DW_AT_external [DW_FORM_flag_present] (true)
                        DW_AT_accessibility [DW_FORM_data1] (0x01)
…

Declaration:   -- no DW_AT_decl_file
0x000164c1:   DW_TAG_subprogram [228] *
                DW_AT_specification [DW_FORM_ref4]  (cu + 0x48ea => {0x00004c0a})
                DW_AT_inline [DW_FORM_data1]  (0x01)
                DW_AT_object_pointer [DW_FORM_ref4] (cu + 0x161ac => {0x000164cc})

…

Inline function call
0x0001657b:     DW_TAG_inlined_subroutine [140] *
                  DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 0x161a1 => {0x000164c1})
                  DW_AT_low_pc [DW_FORM_addr] (0x000000000040fa6e)
                  DW_AT_high_pc [DW_FORM_data4] (0x00000055)
                  DW_AT_call_file [DW_FORM_data1] (0x1a)
                  DW_AT_call_line [DW_FORM_data1] (0xe2)
```

Here is an example for class inline member function declared and defined in different files:

```
Definition:  DW_AT_decl_file: 0x01  --> SymbolizerTestUtils.h
0x00004c3d:           DW_TAG_subprogram [55] *
                        DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0017717f] = "_ZNK5folly10symbolizer4test22InlineFunctionsWrapper9inlineBarERNS0_10FrameArrayILm100EEE")
                        DW_AT_name [DW_FORM_strp] ( .debug_str[0x00089a73] = "inlineBar")
                        DW_AT_decl_file [DW_FORM_data1] (0x01)
                        DW_AT_decl_line [DW_FORM_data1] (0x30)
                        DW_AT_declaration [DW_FORM_flag_present]  (true)
                        DW_AT_external [DW_FORM_flag_present] (true)
                        DW_AT_accessibility [DW_FORM_data1] (0x01)

…

Declaration:   DW_AT_decl_file: 0xbf  --> SymbolizerTestUtils-inl.h
0x00017ee8:   DW_TAG_subprogram [231] *
                DW_AT_decl_file [DW_FORM_data1] (0xbf)
                DW_AT_decl_line [DW_FORM_data1] (0x21)
                DW_AT_specification [DW_FORM_ref4]  (cu + 0x491d => {0x00004c3d})
                DW_AT_inline [DW_FORM_data1]  (0x01)
                DW_AT_object_pointer [DW_FORM_ref4] (cu + 0x17bd5 => {0x00017ef5})

…

Inline function call
0x00017fa5:     DW_TAG_inlined_subroutine [158] *
                  DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 0x17bc8 => {0x00017ee8})
                  DW_AT_low_pc [DW_FORM_addr] (0x00000000004104ee)
                  DW_AT_high_pc [DW_FORM_data4] (0x00000055)
                  DW_AT_call_file [DW_FORM_data1] (0x1a)
                  DW_AT_call_line [DW_FORM_data2] (0x0101)
```

Reviewed By: luciang

Differential Revision: D19444082

fbshipit-source-id: 5a552404609073af04b0cc0b86b5e19d5149a1e1

Summary: Linkage name (DW_AT_linkage_name) contains more information than the identifier name (DW_AT_name).

Reviewed By: luciang

Differential Revision: D19437477

fbshipit-source-id: 1755a71678cbe9e90ba7bc085e4c46b7784c273e

Summary:
Actually class inline functions exist in both .debug_info and .debug_types sections. In this diff, only the information in .debug_info is used.

Step 1. Find the DW_TAG_inlined_subroutine debug info entry (DIE) based on the given address.
Step 2. Find the DW_TAG_subprogram DIE based on the DW_AT_abstract_origin attr in inlined_subroutine, but this DIE is just a declaration.
Step 3. Find the actual definition DW_TAG_subprogram DIE based on the DW_AT_specification attr.

```
.debug_info

0x00003657:           DW_TAG_subprogram [56] *   ---- step 3
                        DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0002932d] = "_ZN5folly10symbolizer4test24ClassWithInlineFunctions9inlineBarERNS0_10FrameArrayILm100EEE")
                        DW_AT_name [DW_FORM_strp] ( .debug_str[0x00014064] = "inlineBar")
                        DW_AT_decl_file [DW_FORM_data1] (0x18)
                        DW_AT_decl_line [DW_FORM_data1] (0xa1)
                        DW_AT_declaration [DW_FORM_flag_present]  (true)
                        DW_AT_external [DW_FORM_flag_present] (true)
                        DW_AT_accessibility [DW_FORM_data1] (0x01)

…

0x0000cd74:   DW_TAG_subprogram [203] * .   ---- step 2
                DW_AT_specification [DW_FORM_ref4]  (cu + 0x358f => {0x00003657})
                DW_AT_inline [DW_FORM_data1]  (0x01)
                DW_AT_object_pointer [DW_FORM_ref4] (cu + 0xccb7 => {0x0000cd7f})

…
0x0000cda0:   DW_TAG_subprogram [181] *
                DW_AT_low_pc [DW_FORM_addr] (0x00000000002a4980)
                DW_AT_high_pc [DW_FORM_data4] (0x00001e22)
                DW_AT_frame_base [DW_FORM_exprloc]  (<0x1> 56 )
                DW_AT_object_pointer [DW_FORM_ref4] (cu + 0xccf0 => {0x0000cdb8})
                DW_AT_specification [DW_FORM_ref4]  (cu + 0x312f => {0x000031f7})

…

0x0000ce02:     DW_TAG_inlined_subroutine [157] *               ---- step 1
                  DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 0xccac => {0x0000cd74})
                  DW_AT_low_pc [DW_FORM_addr] (0x00000000002a4f66)
                  DW_AT_high_pc [DW_FORM_data4] (0x000000c0)
                  DW_AT_call_file [DW_FORM_data1] (0x18)
                  DW_AT_call_line [DW_FORM_data1] (0xe6)

.debug_types

0x00020fdf:         DW_TAG_class_type [33] *
                      DW_AT_calling_convention [DW_FORM_data1]  (0x05)
                      DW_AT_name [DW_FORM_strp] ( .debug_str[0x00067094] = "ClassWithInlineFunctions")
                      DW_AT_byte_size [DW_FORM_data1] (0x08)
                      DW_AT_decl_file [DW_FORM_data1] (0x18)
                      DW_AT_decl_line [DW_FORM_data1] (0x9f)

…

0x00020ff5:           DW_TAG_subprogram [56] *
                        DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0002932d] = "_ZN5folly10symbolizer4test24ClassWithInlineFunctions9inlineBarERNS0_10FrameArrayILm100EEE")
                        DW_AT_name [DW_FORM_strp] ( .debug_str[0x00014064] = "inlineBar")
                        DW_AT_decl_file [DW_FORM_data1] (0x18)
                        DW_AT_decl_line [DW_FORM_data1] (0xa1)
                        DW_AT_declaration [DW_FORM_flag_present]  (true)
                        DW_AT_external [DW_FORM_flag_present] (true)
                        DW_AT_accessibility [DW_FORM_data1] (0x01)

```

Reviewed By: luciang

Differential Revision: D19384064

fbshipit-source-id: a2a6397b94aab9de58d013cf4ad19e658e180d31

Summary: In cases where `addBenchmark` is called directly the name often resides in `std::string` which requires calling `c_str()`. Make it possible to pass `std::string` by making the function take `StringPiece` instead of `const char*`.

Reviewed By: rhodo

Differential Revision: D19507553

fbshipit-source-id: 49dd2bb77daefffeda3fc2153215de77b530f214

Summary: When building folly with clang, backtrace was marked as not found. This diff uses `find_package(Backtrace)` instead which allowed us to use the symbolizer libs.

Reviewed By: simpkins

Differential Revision: D19497120

fbshipit-source-id: a8f8b4ffe9a2d53a53b6c7be32ac2a832a840877

Summary: Use functional style cast on literal value instead of static_cast

Reviewed By: yfeldblum, jdonald

Differential Revision: D19459138

fbshipit-source-id: 103f644322394779fc5cd8512d7a5244d2231091

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

The current documentation for Folly::synchronize_rcu and Folly::rcu_barrier is lacking, this commit adds comment headers.

Reviewed By: magedm

Differential Revision: D18618910

fbshipit-source-id: 39e18d52b2380234ec6f33a1ec220acc97abdd50