Summary:This depends on D2897095.

The main goal here is to start moving onRequestSuccess and onRequestFailure calls higher in the stack.

Reviewed By: mmcduff

Differential Revision: D2899959

fb-gh-sync-id: 4e074c2d734f88f5be56000095b892c6d47c0dcc
shipit-source-id: 4e074c2d734f88f5be56000095b892c6d47c0dcc

Summary: Update copyright for 2016

Reviewed By: igorsugak

Differential Revision: D2828047

fb-gh-sync-id: 8638188aeb694c3ca2a615cc2bc3bc9d251e388d
shipit-source-id: 8638188aeb694c3ca2a615cc2bc3bc9d251e388d

Summary: This adds a folly::Singleton->folly::ThreadLocal dependency to make sure folly::ThreadLocal is always loaded first. Otherwise PthreadKeyUnregister singleton is created after folly::Singleton storage, even though it has higher priority.

Reviewed By: andrewjcg

Differential Revision: D2931170

fb-gh-sync-id: 36392d76e98201f2b4416b4bbef451d6c0e8c69d
shipit-source-id: 36392d76e98201f2b4416b4bbef451d6c0e8c69d

Summary:I hit a landmine where rate() returned 0 for my tests where fewer than 60 items were added per minute.  This was because it was truncating it.  And yet, countRate() was working.
It doesn't make sense for a rate (value accumulated per time period) to be integral.
Folly: I changed rate() to return a double by default for folly, as was done by avg() and countRate().  Looked like a typo to me.
Common wrapper: I changed getRate() to allow you to override and make it double, as was done by getAvg().  Defaulting to int (which is usually the value type) is a bad call IMO but it's a riskier change to change it to double, and I want to be consistent with getAvg().

Reviewed By: tracelog

Differential Revision: D2921061

fb-gh-sync-id: 00875f2ab7963ef3ba2db475aedaf6ebd413b38f
shipit-source-id: 00875f2ab7963ef3ba2db475aedaf6ebd413b38f

Summary: Didn't check this with -Wshadow when I first wrote it.

Reviewed By: ranjeeth

Differential Revision: D2926047

fb-gh-sync-id: 8391986dee2d6b5698491bd2995f039468ec684d
shipit-source-id: 8391986dee2d6b5698491bd2995f039468ec684d

Summary: It should be UL instead of ULL.

Reviewed By: siyengar

Differential Revision: D2926005

fb-gh-sync-id: d2387eb601c50d9820907c831277aa6f8e938cbb
shipit-source-id: d2387eb601c50d9820907c831277aa6f8e938cbb

Summary: Remove boost regex from `stripLeftMargin`. We can shrink some binaries by not including it in the core folly library.

Reviewed By: yfeldblum

Differential Revision: D2922415

fb-gh-sync-id: cee89164c650706f0e5c07eed3d40500831918cd
shipit-source-id: cee89164c650706f0e5c07eed3d40500831918cd

Summary: We want onThreadExit to be canceled as late as possible. Otherwise accessAllThreads() may crash on shutdown (because ThreadEntry is destroyed, but not removed from the global list).

Reviewed By: igorsugak

Differential Revision: D2923435

fb-gh-sync-id: 3a8eef05844bb547c06db33cb96734df1169852a
shipit-source-id: 3a8eef05844bb547c06db33cb96734df1169852a

Summary:
When compiled for -m32, this test fails because of the
difference between longs.

Reviewed By: yfeldblum

Differential Revision: D2924626

fb-gh-sync-id: 8ee863fa2b6df8519bd52d0d3144697a297780bb
shipit-source-id: 8ee863fa2b6df8519bd52d0d3144697a297780bb

Summary: Avoid allocation and logging inside the throw handler, and some other minor tweaks.

Reviewed By: bort, luciang

Differential Revision: D2921073

fb-gh-sync-id: 4491ab2f85a4251e59ba9394bba5abef0bdf7a10
shipit-source-id: 4491ab2f85a4251e59ba9394bba5abef0bdf7a10

Summary:
Previously we could be reading from thread-local FiberManagerMap while it was modified.
This is now fixed by keeping a per-thread list of EventBases which need to be removed from local maps. On the fast-path no action is taken, since list will be empty.

This is second try, since D2853921 got reverted.
The new implementation is simpler and does not rely on AtomicLinkedList.

Reviewed By: yfeldblum

Differential Revision: D2908018

fb-gh-sync-id: 4d7aed974c19761f7e2732ddbf8694af57c69bd6
shipit-source-id: 4d7aed974c19761f7e2732ddbf8694af57c69bd6

Summary:
[Folly] `stripLeftMargin`.

So you can do:

    TEST(MyClass, doSomethingWithString) {
      //  Multiline string literal is indented properly inside the test case
      //  instead of being aligned all the way to the left, which would make
      //  the test case read poorly.
      auto input = folly::stripLeftMargin(R"TEXT(
        first line
        second line
        third line
      )TEXT");
      auto expected = //...
      auto actual = MyClass::doSomethingWithString(input);
      EXPECT_EQ(expected, actual);
    }

Reviewed By: markisaa

Differential Revision: D2909736

fb-gh-sync-id: ebb07da05e1a788535064cfcd9e07f617a007800
shipit-source-id: ebb07da05e1a788535064cfcd9e07f617a007800

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