Summary:
HHWheelTimer's auto-pointers are kind of funny.  You can do something like this:

```
HHWheelTimer::UniquePtr p = ...;
// create a SharedPtr from UniquePtr
HHWheelTimer::SharedPtr s(p);
// create another SharedPtr from raw ptr
HHWheelTimer::SharedPtr s(p.get());
// No problem.

If you do this:

HHWheelTimer::SharedPtr p = ....;
// this leaks
```

Why?  Because SharedPtr is only have of std::shared_ptr.  It's the refcounting half.  But when the last SharedPtr goes out of scope, it **does not** invoke HHWheelTimer::destroy().

So code like this is possible/expected:

```
MySweetObj::MySweetObj(HHWheelTimer::SharedPtr s) {
  s_ = s;
  s_.scheduleTimeout(a, b);
}

{
  HHWheelTimer::UniquePtr p = ...;

  obj = MySweetObj(p)

  // But what if I decide to kill p:
  p.reset();
}
```

Since MySweetObj takes a SharedPtr and holds it, it can reasonbly expect that it can schedule timeouts on it, and the HHWheelTimer will not be deleted until it releases the SharedPtr.  This is true, but the above code would hit the assert that count_ == 0.

Instead, relase the check that count_ == 0 only if there are no extra outstanding SharedPtrs.

Reviewed By: viswanathgs, chadparry

Differential Revision: D2908729

fb-gh-sync-id: 9abd4a7d692fe952c5514dbb8d85dfbad95a3cac
shipit-source-id: 9abd4a7d692fe952c5514dbb8d85dfbad95a3cac

Summary:
FBStringTest.cpp was refactored, but the TestUtil and
TemporaryFile was not properly removed.

Reviewed By: yfeldblum

Differential Revision: D2913045

fb-gh-sync-id: 710c3f5b808acb634dfcd65219484ddc257ed52c

Summary:
[Folly] Fix Build: `conditionally_existent_test` in `folly/test/Makefile.am`.

HT: https://github.com/shindo.

Reviewed By: meyering

Differential Revision: D2910782

fb-gh-sync-id: 9593f026e7c58b8644abc5996da65005bcc2d095

Summary:
folly::Future (more precisely folly::detail::Core) can store
callback functors (typically lambdas) up to a certain size
(8*sizeof(void*)) inside the main object. Only bigger functors
are stored in the std::function object in folly::detail::Core,
which will put them on the heap.

The behaviour of folly::Future is slightly different depending
on whether the callback can be embedded in the main object
or not. Small functors will be destructed after the callback
is executed. Functors too big to fit in the lambda space in
the Core object will be deleted when Core is deleted.

Some code assumes that functor objects are deleted as soon
as the callback has been executed. The implementations of
folly::Future::collect and variants do so. If you switch
off this optimisation temporarily (which can be done easily
by setting lambdaBufSize in folly/futures/detail/Core.h to
0), a number of unit tests fail.

Given that the lambda buffer is reasonably large, most
functors can be stored in the Core object. The different
behaviour for very large lambdas may not have been observed.

This diff fixes the inconsitent behaviour.

Firstly, it changes the unit test Future:finish to explicitly
check that the callback functor is deleted after the callback
has been executed. This should be tested, because this
behaviour is assumed in other parts of the futures
implementation (e.g. Future::collect et al.).

Secondly, it adds another unit test Future:finishBigLambda,
similar to Future:finish. The lambda captures much more data
to make sure the lambda won't be stored in the Core object,
but in the std::function object inside Core. The test verifies
that the behaviour is the same, i.e. the callback functor
is destructed after the callback has been executed.

Thirdly, it fixes Core and makes sure that functors of any
size are destructued after the callback has been called. The
new unit test fails without this.

Reviewed By: fugalh

Differential Revision: D2883772

fb-gh-sync-id: 21a410f6592b3e090772a7b55bef6729d8739922

Reviewed By: philippv

Differential Revision: D2900534

fb-gh-sync-id: c711a160d541d937ada24f2b524016dbceb40ee2

Summary: Due to different way of padding, CoreTest failed on android. Loosen the check to make it pass.

Reviewed By: mzlee

Differential Revision: D2907987

fb-gh-sync-id: 81d715725d6908ec7b259b0a67789a91ed63df71

Summary: Some small changes to port folly/futures onto android

Reviewed By: mzlee

Differential Revision: D2787564

fb-gh-sync-id: 8c161942c24c2b7b0484339eaa51c5a356f17de5

Summary:
[Folly] `ConditionallyExistent<typename>`.

For when we need extra member fields in dbg builds, but want to save the space in opt builds. Or other situations along similar lines, but with perhaps another the statically-known condition.

Conditional compilation can have some nasty side-effects. Best to avoid it. Let the compiler see everything, rather than having the preprocessor ruin our day. Let the optimizer remove code that will never be called, after the compiler has seen it. Let us have a single AST in our source file, not one AST for dbg and one for opt, or other statically-known conditions.

Reviewed By: andriigrynenko

Differential Revision: D2879397

fb-gh-sync-id: d631141a984eebd46674f27a40a97f670eb33f54

Summary: This was causing memory leaks. I assume that happens if FiberManager was once requested from a thread (so that thread local was initialized), but the thread was never used since then, accumulating EventBase* in the queue.

Reviewed By: simonmar

Differential Revision: D2906752

fb-gh-sync-id: 71ab14cb051a9cee3684a30eaf6729ef65888a52

Summary:
The wstring support on KitKat is not exactly working.  Works
on Lollipop though.

Reviewed By: markisaa

Differential Revision: D2901732

fb-gh-sync-id: 97b57fb4d8c645192be62dca25d8fb1b2397ad7d

Summary: See title. This is create a big flat mess, which I may clean up in a follow on to highlight the biggest and most generally useful libraries.

Reviewed By: fugalh

Differential Revision: D2902152

fb-gh-sync-id: 028633448ab97f47a3419f31fa58c79b77a89e52

Summary: See title

Reviewed By: snarkmaster

Differential Revision: D2901817

fb-gh-sync-id: 5b9ede7b941cf18e7be352a93ec5686e6f1f50a7

Summary: Adds functionality to fibermanager to add tasks locally and remotely that will return futures. As a side effect, also wraps the function in addTaskRemote in a move wrapper so that it behaves correctly with move-only types such as promises.

Reviewed By: andriigrynenko, yfeldblum

Differential Revision: D2892898

fb-gh-sync-id: 1666c103db35d9c149c36f8b8c3058cd6e0465fc

Summary: Avoid using folly::ThreadLocal on the fast-path. This uses the fact that it is a static object.

Reviewed By: yfeldblum

Differential Revision: D2873374

fb-gh-sync-id: 978108da0c9e8576fda6849058b0262478c2841e

Summary: The session callbacks assumed that the SSL* was associated with a folly::AsyncSSLSocket when it didn't need to.  This enables apps that manage their own SSL* to use these callbacks.

Reviewed By: yfeldblum

Differential Revision: D2896426

fb-gh-sync-id: c51df6b4cb3f4cc188a6411c1f3e7e89e96e8a67

Summary: See comment.

Reviewed By: juancarabina, luciang

Differential Revision: D2896262

fb-gh-sync-id: cb884651d47b86c0a5b3c2c22f421b2b1f39dc35

Summary: TimeoutManager is a Mockable parent class

Reviewed By: maxgeorg

Differential Revision: D2892671

fb-gh-sync-id: d20635b18a7c748009ce4880c80a13ac23b9222a

Summary: - Add new MockTimeoutManager mock. For testing.

Reviewed By: yfeldblum

Differential Revision: D2891814

fb-gh-sync-id: 6d15feb533e5a8984484d1efdf58d2c77b7b3f49

Summary:
To support consuming Watchman from within fbcode and hhvm
in particular, these functions add a BSER serialization for the
folly::dynamic data type.

Reviewed By: bhamiltoncx

Differential Revision: D2876539

fb-gh-sync-id: bc49d6bc453cc66cebda7185a5907a6f70970b24

Summary: added missed boost dependency and changed CMake build order

Reviewed By: snarkmaster, yfeldblum

Differential Revision: D2878880

fb-gh-sync-id: 2a5cded97afde4fd0d741168c3296f2c71426374

Summary: Add some quick comments about folly::fiber implementation classes.

Reviewed By: yfeldblum

Differential Revision: D2891940

fb-gh-sync-id: b9899bb63df03f32763f93a5dae8dff94c8e354e

Summary:
`writeTerminator` needs to determine the string category, and in the small case, also its size. This information is often known, but the compiler cannot optimize it away especially if `capacity_` was just overwritten. Also, some occurrences are just redundant. We can remove the latter and specialize the former.

Small operations such as `push_back` are up to 40% faster.

Before/after:
```
$ ./fbstring_benchmark_using_jemalloc --bm_regex '_fbstring' --bm_min_usec 200000 --bm_max_secs 2
============================================================================ ===================
./folly/test/FBStringTestBenchmarks.cpp.h       relative  time/iter  iters/s  time/iter  iters/s
============================================================================ ===================
BM_initRNG_fbstring(0)                                       0.00fs  Infinity    0.00fs  Infinity
BM_defaultCtor_fbstring(0)                                   6.82us  146.60K     6.26us  159.74K
BM_copyCtor_fbstring(32768)                                 16.86ns   59.32M    15.50ns   64.52M
BM_ctorFromArray_fbstring(32768)                             2.25us  444.78K     2.12us  471.58K
BM_ctorFromTwoPointers_fbstring(0)                           9.76ns  102.44M     7.85ns  127.35M
BM_ctorFromTwoPointers_fbstring(7)                           9.68ns  103.32M     8.10ns  123.47M
BM_ctorFromTwoPointers_fbstring(15)                          9.77ns  102.34M     8.12ns  123.17M
BM_ctorFromTwoPointers_fbstring(23)                          9.46ns  105.68M     8.78ns  113.88M
BM_ctorFromTwoPointers_fbstring(24)                         31.23ns   32.02M    30.71ns   32.56M
BM_ctorFromChar_fbstring(1048576)                           40.04ns   24.97M    35.68ns   28.03M
BM_assignmentOp_fbstring(256)                               66.76ns   14.98M    63.93ns   15.64M
BM_assignmentFill_fbstring(0)                                8.23ns  121.47M     7.02ns  142.49M
BM_resize_fbstring(524288)                                   4.09us  244.63K     3.94us  253.84K
BM_equality_fbstring(65536)                                  2.47ms   404.63     2.19ms   455.92
BM_replace_fbstring(256)                                   172.36ns    5.80M   159.10ns    6.29M
BM_push_back_fbstring(1)                                     9.32ns  107.27M     7.79ns  128.40M
BM_push_back_fbstring(23)                                  252.44ns    3.96M   158.31ns    6.32M
BM_push_back_fbstring(127)                                 721.50ns    1.39M   515.08ns    1.94M
BM_push_back_fbstring(1024)                                  5.21us  191.87K     3.14us  318.03K
BM_short_append_fbstring(23)                               431.71ns    2.32M   335.74ns    2.98M
BM_short_append_fbstring(1024)                              11.96us   83.64K     9.19us  108.78K
BM_getline_fbstring(23)                                     57.06ns   17.53M    39.78ns   25.14M
BM_getline_fbstring(1000)                                  232.26ns    4.31M   203.24ns    4.92M
============================================================================ ===================

```

(`find` benchmarks were removed due to high variance caused by randomness)

Reviewed By: luciang

Differential Revision: D2879646

fb-gh-sync-id: 10fd8573495d285220ae98858d11de9ec6d97e54

Summary: This was falling back to a hard depency on JEMalloc, and MSVC doesn't have proper weak linkage, so emulate it with some linker magic to get things building.

Reviewed By: yfeldblum

Differential Revision: D2887695

Pulled By: Orvid

fb-gh-sync-id: 50c812a07c4e4e5bbe71263b86386783bf76ba82

Summary:
Undefined Sanitizer doesn't define any macro to detect that it's active.

The build system should provide `-DUNDEFINED_SANITIZER` when building
with -fsanitize=undefined or any of the other flags from
http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

FWIW: Chrome defines the same preprocessor symbol:
https://chromium.googlesource.com/chromium/src/+/ac18f489dca8c902e4dfaa1a28d716b7914121d0%5E%21/build/common.gypi

Reviewed By: andrewjcg

Differential Revision: D2885167

fb-gh-sync-id: e1129c0863bfde5d032c32e7d5cea7c43d82009f

Summary: Depends on D2865911

Reviewed By: luciang

Differential Revision: D2742158

fb-gh-sync-id: 3e7866a742575ee4f7501cff0abbd5c21e26a46e

Reviewed By: philippv

Differential Revision: D2886132

fb-gh-sync-id: a845d657fb920847df52fe5ec077e91554544f5b

Summary: The usage is guarded by a preprocessor macro, and I didn't noticed this earlier.

Reviewed By: yfeldblum

Differential Revision: D2887016

fb-gh-sync-id: 791c4d16475aab77235792953997a281354018e9

Summary:
I want to be able to include this in
fbobjc/xplat/folly:headers_only, but it currently pulls in a boost
header and Portability.h. Fortunately, neither of those includes are
needed.

Reviewed By: ddrcoder, yfeldblum, mhorowitz

Differential Revision: D2880443

fb-gh-sync-id: 409561b8fb555ac3946d59cd6657c6c643b67c86

Summary: MSVC doesn't support evaluating strlen at compile time, so implement our own version instead.

Reviewed By: yfeldblum, lbrandy

Differential Revision: D2856926

fb-gh-sync-id: 22222350b57d9eff6a06c9d0f37d43a3cb1f2534

Reviewed By: philippv

Differential Revision: D2886152

fb-gh-sync-id: 64c3543db831c72c7f4cf307867223270293066e

Summary:
  [ RUN      ] Hash.TWang_Unmix64
  folly/test/HashTest.cpp:125:20: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'

Reviewed By: philippv

Differential Revision: D2886144

fb-gh-sync-id: 8d7963c087c9db34b08c07451d35e5568c750520

Summary: Fix a few `-Wmissing-field-initializers` exposed by clang.

Reviewed By: yfeldblum

Differential Revision: D2881902

fb-gh-sync-id: 67fdffd39d3ccca64f84055adae1f3b47fdec633

Summary:
Document what the enum settings mean since they can be
somewhat confusing.

Reviewed By: shamdor-fb

Differential Revision: D2882929

fb-gh-sync-id: 74ec30132bf5d2dce42f51a0b7b30cf2fae12dbf

Summary: Fix a few remaining unused parameters, that are exposed only in opt build.

Reviewed By: markisaa

Differential Revision: D2878865

fb-gh-sync-id: d0d9761362220973cda14d99ab7342fbe8b1a469

Summary: Fix a few unused const variables exposed by clang's `-Wunused-const-variable`.

Reviewed By: yfeldblum

Differential Revision: D2878944

fb-gh-sync-id: f5500fda4782eac2964761c0398d016d57716269

Summary:
Winsock doesn't like it when you try to call getsockname on a socket that hasn't yet been connected or bound, because that socket doesn't have a name yet.
This only occurred because we were trying to get the family of the socket.
To solve this, I just passed the family in from the parent methods that already knew what the family was.

Reviewed By: yfeldblum

Differential Revision: D2871859

Pulled By: Orvid

fb-gh-sync-id: 7674f565a968aa0258355fc977c185a416e4fbe4

Summary:
There is no universally accessible tmpdir on Android which
means mkstemp fails. This diff calls a function that the test runner
should provide to fill a valid temporary directory.

Reviewed By: yangchi

Differential Revision: D2842034

fb-gh-sync-id: 9b826757bd750af016a18adccd5a21174be644d6

Summary: In order to avoid mandatory dependncy on elf, dwarf, unwind made new init function optional

Reviewed By: markisaa

Differential Revision: D2878545

fb-gh-sync-id: f66d3884a531dcf56fc1432330325ab45b149d7f

Summary: This was showing up on a Linux compile to my sadness.

Reviewed By: francis-ma

Differential Revision: D2876010

fb-gh-sync-id: f638d593712c0aeb50177d96aaacb26575820359

Summary:
Current `getline` implementation in `fbstring` always allocates, even if the passed string is already large enough. Furthermore, the growing strategy relies on outdated assumptions about the allocator.
This implementation reuses the existing allocation as much as possible, then uses exponential growth.

Reviewed By: luciang, philippv

Differential Revision: D2871976

fb-gh-sync-id: 8db9512030be3f4953efa8f008747827504c032c