Summary: `AsyncServerSocket::bind()` would not give information like port or family name when failing to bind a socket. This diff addresses that by including this information in the exception. Two additional helper methods were added to `SocketAddress` to retrieve both the port and the family name from a `sockaddr` structure.

Reviewed By: ckwalsh, yfeldblum

Differential Revision: D3249778

fb-gh-sync-id: 4edb28af5c211b7bf8d525b40844a5b0b6261e07
fbshipit-source-id: 4edb28af5c211b7bf8d525b40844a5b0b6261e07

Summary: This diff fixes a problem with passing move-only types to folly::via.

Reviewed By: ericniebler

Differential Revision: D3254906

fb-gh-sync-id: 8a9c703a8db0ccf20b9fb4fe9b80ad6cdcb3e388
fbshipit-source-id: 8a9c703a8db0ccf20b9fb4fe9b80ad6cdcb3e388

Summary:
[Folly] Deprecate `boost::mpl`.

The `std` has equivalents; prefer them.

Reviewed By: Gownta

Differential Revision: D3247294

fb-gh-sync-id: 873697b7ea3ad069ff14662bc458a2e1cc840339
fbshipit-source-id: 873697b7ea3ad069ff14662bc458a2e1cc840339

Summary: It's there for a reason, so use it.

Reviewed By: yfeldblum

Differential Revision: D3249849

fb-gh-sync-id: e9fe330693a173acd987e0c8fd1f03a982c8e082
fbshipit-source-id: e9fe330693a173acd987e0c8fd1f03a982c8e082

Summary:
This is only an issue for the OSS HHVM build on OSX, where we have JEMalloc headers included directly.
In the OSS HHVM build, we define `USE_JEMALLOC` globally if we have JEMalloc, so gate the portability implementation behind that.

Reviewed By: mzlee

Differential Revision: D3237449

fb-gh-sync-id: 07cf9b31114723ffd9f2b29cf449bee0ed8f5703
fbshipit-source-id: 07cf9b31114723ffd9f2b29cf449bee0ed8f5703

Summary:
We should use the appropriate AsyncSocketExceptionType when firing SSLExceptions.  This derives the type from the constructor args, and introduces a `NETWORK_ERROR` exception type.  Open to suggestions on reusing something there.

Additionally, rename getType() to getSSLError() to prevent hiding the AsyncSocketException::getType.

Reviewed By: siyengar

Differential Revision: D3241204

fb-gh-sync-id: de631dfb3554177d5bd561f4b91e767c882767d3
fbshipit-source-id: de631dfb3554177d5bd561f4b91e767c882767d3

Summary:
This diff unifies the nearly-replicated call paths for ECDSA and RSA
sign request/response/fallback/etc. into one generic futures-based sign API.
Once this is tested, we should be able to remove ~500 lines of code from
CryptoSSLRequestManager

Depends on D3094660

Reviewed By: siyengar

Differential Revision: D3116535

fb-gh-sync-id: 11c50d81dab39e5426679b5a172c1ece2039fc10
fbshipit-source-id: 11c50d81dab39e5426679b5a172c1ece2039fc10

Summary:
[Folly] Avoid glog when warning about `Singleton` double-registration.

Because registration happens at static initialization time, long before main, and possibly long before glog is initialized.

This makes a difference because, in some cases of double-registration, we can get a SIGSEGV with no message, because we are attempting to `LOG(FATAL)` when glog is uninitialized. What we would much rather have is a SIGABRT with a message.

Reviewed By: meyering

Differential Revision: D3245047

fb-gh-sync-id: 4c5dd9d25025f197d7c490ffbb429af5ccb82182
fbshipit-source-id: 4c5dd9d25025f197d7c490ffbb429af5ccb82182

Summary:
In D3241498 addTaskFuture was fixed to work with function returning void. This however changed addTaskFinally API to not allow finally functor which accepts Try<void>.

folly::fibers generally supports Try<void> so there's no reason to force users to use folly::Unit instead of void for addTaskFinally too.

Reviewed By: yfeldblum

Differential Revision: D3243893

fb-gh-sync-id: d1df54738157d2019120103956f59b3971ba25ff
fbshipit-source-id: d1df54738157d2019120103956f59b3971ba25ff

Summary:
There's no Future<void>, you're supposed to use Future<Unit>
instead.  Unit has a "Lift" template to do the conversion.

Reviewed By: andriigrynenko

Differential Revision: D3241498

fb-gh-sync-id: db12d4f343685bc613b701e023c860c2c903ed4c
fbshipit-source-id: db12d4f343685bc613b701e023c860c2c903ed4c

Summary: Clang-format in preparation for other change

Reviewed By: andriigrynenko

Differential Revision: D3241297

fb-gh-sync-id: b7b26812e9e61c291d5c7bdb523df8f28f2d9b4f
fbshipit-source-id: b7b26812e9e61c291d5c7bdb523df8f28f2d9b4f

Summary:
As it might be used during global destruction (for example, to
symbolize unhandled exception happened at that time).

Reviewed By: luciang, ot

Differential Revision: D3238303

fb-gh-sync-id: 39d8a6f99d95e700586349436e961f3624c95718
fbshipit-source-id: 39d8a6f99d95e700586349436e961f3624c95718

use std::forward instead of std::move on objects whose types have been deduced; don't take the sizeof incomplete types

Summary: Pretty sure std::forward is needed here instead of std::move. If you trace the call chain to see where the types of the objects come from, you'll see they can be deduced to be lvalues, so std::forward is the right choice. Also, moved some dicey looking code that appeared to be taking the size of some incomkplete types.

Reviewed By: spacedentist

Differential Revision: D3214199

fb-gh-sync-id: 778190ffb25a648b839760a3dddfad8dc6d41c88
fbshipit-source-id: 778190ffb25a648b839760a3dddfad8dc6d41c88

Summary:
Currently you need to depend on the destructor of `ReadHolder` (using closures as in code block #1 below or empty assignment as in code block #2 below) to ensure that a `ReadHolder` goes out of scope (and unlocks) in order to subsequently acquire a write lock via `WriteHolder` without deadlocking.
This diff introduces a way of unlocking a `ReadHolder` while it's still in scope such that a `WriteHolder` can be acquired. This makes the code more straight forward (reducing the risk of deadlock due to a programmer's misunderstanding of how `SharedMutex` / the holder framework works) => see code block # 3 below
Also add some documentation about why `WriteHolder::WriteHolder(ReadHolder&&)` doesn't exist

Code Block #1 : Use of closures
```
class foo {
 public:
  std::string getMemoizedData() {
    {
      folly::SharedMutex::ReadHolder readHolder(lock_);
      if (!data_.empty()) {
        // important to return by value, otherwise caller might access
        // data_ after we release the read lock
        return data_;
      }
    }
    {
      // try again with a write lock
      folly::SharedMutex::WriteHolder writeHolder(lock_);
      if (data_.empty()) {
        data_ = "my awesome string";
      }
      return data_;
    }
  }

 private:
  folly::SharedMutex lock_;
  std::string data_;
};
```

Code Block #2 : Use of empty assignment
```
class foo {
 public:
  std::string getMemoizedData() {
    folly::SharedMutex::ReadHolder readHolder(lock_);
    if (!data_.empty()) {
      // important to return by value, otherwise caller might access
      // data_ after we release the read lock
      return data_;
    }
    readHolder = {};

    // try again with a write lock
    folly::SharedMutex::WriteHolder writeHolder(lock_);
    if (data_.empty()) {
      data_ = "my awesome string";
    }
    return data_;
  }

 private:
  folly::SharedMutex lock_;
  std::string data_;
};
```

Code Block #3 : Use of unlock()
```
class foo {
 public:
  std::string getMemoizedData() {
    folly::SharedMutex::ReadHolder readHolder(lock_);
    if (!data_.empty()) {
      // important to return by value, otherwise caller might access
      // data_ after we release the read lock
      return data_;
    }
    readHolder->unlock();

    // try again with a write lock
    folly::SharedMutex::WriteHolder writeHolder(lock_);
    if (data_.empty()) {
      data_ = "my awesome string";
    }
    return data_;
  }

 private:
  folly::SharedMutex lock_;
  std::string data_;
};
```

Reviewed By: yfeldblum

Differential Revision: D3176025

fb-gh-sync-id: c7d47ca71df08673c7c1f1fd5ed9e01a663c1797
fbshipit-source-id: c7d47ca71df08673c7c1f1fd5ed9e01a663c1797

Summary: A few code cleanups, no functionality changes.

Reviewed By: ericniebler

Differential Revision: D3231369

fb-gh-sync-id: 1a1c8508aab6dce7279e9dfc3f3da6add5496c67
fbshipit-source-id: 1a1c8508aab6dce7279e9dfc3f3da6add5496c67

Summary:
Better enum exception types for SSLException.
These enum types are fairly high level, and more
info can be gleaned from the error.what()

Reviewed By: knekritz

Differential Revision: D3234501

fb-gh-sync-id: 7cd4fbccd7f4367354dc3bd1fe4cd480d58d6173
fbshipit-source-id: 7cd4fbccd7f4367354dc3bd1fe4cd480d58d6173

Summary:
We abuse errno to propagate exceptions from AsyncSSLSocket.
Stop doing this and propagate exceptions correctly.

This also formats the exception messages better.

Reviewed By: anirudhvr

Differential Revision: D3226808

fb-gh-sync-id: 15a5e67b0332136857e5fb85b1765757e548e040
fbshipit-source-id: 15a5e67b0332136857e5fb85b1765757e548e040

Summary: Add X509 param types

Reviewed By: knekritz

Differential Revision: D3230008

fb-gh-sync-id: 660a2f5bdc9355f5b42c2ccfb1d7cab83df34fc2
fbshipit-source-id: 660a2f5bdc9355f5b42c2ccfb1d7cab83df34fc2

Summary:
The array-bounds checker in gcc complains that r could be -1 after leaving CHECK_ERR in ASAN mode. Switch to DCHECK to avoid this possibility. The code was not initially compiling; now it does.

Error from gcc:
  array subscript is below array bounds [-Werror=array-bounds]

Reviewed By: yfeldblum

Differential Revision: D3232694

fb-gh-sync-id: 17f579eb152b661a8e5e4ed29ef91eec405fb90a
fbshipit-source-id: 17f579eb152b661a8e5e4ed29ef91eec405fb90a

Summary: `small_vector.h` had it's own thing being defined inline, and it was breaking the OSX build of HHVM, so have it use the portability header instead.

Reviewed By: yfeldblum

Differential Revision: D3232885

fb-gh-sync-id: 2078a54d1ec9700e81e0a9f4baed8e2d623fa5f3
fbshipit-source-id: 2078a54d1ec9700e81e0a9f4baed8e2d623fa5f3

Summary:
This fixes 2 races in TLRefCount:
1. Thread-local constructor race, exposed by the stress test. It was possible for LocalRefCount to be created (grabbing collectGuard), but not be added to the thread-local list, so that accessAllThreads wasn't collecting it. collectAll() was then blocking waiting on baton to be posted, causing a dead-lock.
2. LocalRefCount::count_ has to be made atomic, because otherwise += operation may be not flushed (nbronson explained the race in D3133443).

Reviewed By: djwatson

Differential Revision: D3166956

fb-gh-sync-id: 17d58a215ebfc572f8316ed46bafaa5e6a9e2368
fbshipit-source-id: 17d58a215ebfc572f8316ed46bafaa5e6a9e2368

Summary:
Use tag dispatching instead of `enable_if`: it is clearer, it
sidesteps the GCC mangling bug, and more importantly the conditional
doesn't leak into the symbol, making stack traces and profiles more
readable.

Testing on a compilation unit with 1000 `Function`s from simple lambdas.
Before:
```
folly::impl::Function<int (), false>::Function<main::{lambda()#1}, {lambda()#1}>(main::{lambda()#1}&&, std::enable_if<std::integral_constant<bool, ((sizeof (std::decay<main::{lambda()#1}>::type))<=(sizeof folly::detail::function::Data::small))&&std::is_nothrow_move_constructible<std::decay<main::{lambda()#1}> >::value>::value, folly::detail::Tag>::type)::Ops::call(folly::detail::function&)
```
After:
```
folly::impl::Function<int (), false>::OpsSmall<main::{lambda()#1}>::call(folly::detail::function::Data&)
```
Note that the function type is repeated 5 times before, and only once after. This makes a large difference with long namespaces.

Binary size is almost unaffected, compile times slightly better:
Before:
GCC opt: 22.3 seconds, 4435232 bytes
Clang dev: 7.7 seconds, 5257344 bytes

After:
GCC opt: 18.6 seconds, 4493920 bytes
Clang dev: 7.2 seconds, 5469136 bytes

Reviewed By: ericniebler

Differential Revision: D3231530

fb-gh-sync-id: 6aa76e7f780a8afdbfed8a378f257ceb86dce704
fbshipit-source-id: 6aa76e7f780a8afdbfed8a378f257ceb86dce704

Summary: there is no need to call `std::function::invoke` for every DestructorGuard.

Reviewed By: yfeldblum

Differential Revision: D3229345

fb-gh-sync-id: c42f8cd05576d56b6a9b2f9d06878d9b01a36e94
fbshipit-source-id: c42f8cd05576d56b6a9b2f9d06878d9b01a36e94

Summary:
Just like the real thing does.
This was causing some issues when trying to link against glog, which expects the flags to be namespaced like this.

Reviewed By: mzlee

Differential Revision: D3230630

fb-gh-sync-id: a73ab3044560d561a39eb91ceee1588c147a46c5
fbshipit-source-id: a73ab3044560d561a39eb91ceee1588c147a46c5

Summary:
folly::Function is causing significant compile time regressions. Reimplement it in a simpler way.

These are the times for a file containing 1000 instantiations of folly::Fuction (old), folly::Function (new), and std::function with **g++ 4.8 -O3** on my CentOS7 server.

|        | Old `folly::Function` | `std::function` | New `folly::Function` |
|--------|-----------------------|-----------------|-----------------------|
| Time   | 10m37s                | 0m16.81s        | 0m14.75s              |

And for the executable size:

|        | Old `folly::Function` | `std::function` | New `folly::Function` |
|--------|-----------------------|-----------------|-----------------------|
| Size   | 10,409,504            | 732,150         | 562,781               |

That's a **43X** improvement in compile times and an **18X** reduction in executable bloat over the old implementation.

The times for **clang (trunk)** are very different:

|       | Old `folly::Function` | `std::function` | New `folly::Function` |
|-------|-----------------------|-----------------|-----------------------|
| Time  | 4m6s                  | 0m45.27s        | 0m11.78s              |

That's a **20X** improvement over the old implementation and almost a **4X** improvement over `std::function`.

For **gcc-5.3.0**, compile times are again different:

|       | Old `folly::Function` | `std::function` | New `folly::Function` |
|-------|-----------------------|-----------------|-----------------------|
| Time  | 2m49s                 | 0m18.99s        | 0m20.70s              |

With gcc-5.3, the new implementation "only" compiles 8x faster than the old one, and is roughly the same as `std::function`.

Reviewed By: spacedentist, ot, luciang

Differential Revision: D3199985

fb-gh-sync-id: b97982a9dc3a63140510babea34988932e89f2d9
fbshipit-source-id: b97982a9dc3a63140510babea34988932e89f2d9

Summary: Without this, malicious inputs can crash anything using folly::parseJson.

Reviewed By: yfeldblum

Differential Revision: D3219036

fb-gh-sync-id: 3604a060170c0201473c420035b21b018383789c
fbshipit-source-id: 3604a060170c0201473c420035b21b018383789c

Summary: Remove dead code in AsyncSSLSocket.

Reviewed By: knekritz

Differential Revision: D3226948

fb-gh-sync-id: e85823f311de2539c6aa2d6bcc3ff3aee07045bf
fbshipit-source-id: e85823f311de2539c6aa2d6bcc3ff3aee07045bf

Summary: This bug causes failure when the test is run under ASAN.

Reviewed By: meyering

Differential Revision: D3229494

fb-gh-sync-id: a43c8332cc45f7892ac86cd0abb799616bca7779
fbshipit-source-id: a43c8332cc45f7892ac86cd0abb799616bca7779

Summary: no need in virtual call from EventHandler.

Reviewed By: yfeldblum

Differential Revision: D3226960

fb-gh-sync-id: eb9c191630e1a1ac022666201100e3778eb7b611
fbshipit-source-id: eb9c191630e1a1ac022666201100e3778eb7b611

Summary:
'get' is the most frequent memcached operation. On a get reply, we should go to heap
as little as possible.  This diff optimizes for this scenario, where replies
have only one IOBuf field.

Reviewed By: pavlo-fb

Differential Revision: D3226592

fb-gh-sync-id: 92e1a1fac5735bd268691cf11990a96ae6fa8309
fbshipit-source-id: 92e1a1fac5735bd268691cf11990a96ae6fa8309

Summary:
Currently UTF8Range has a constructor that allows you construct an object of type UTF8Range using only an object of type folly::Range. Adding a constructor so that we can construct an UTF8Range object using a std::string.

Currently,
  void sampleMethod(UTF8StringPiece sp) {...}
  /*
  ...
  */
  std::string str = "example";
  folly::UTF8Range utf8Range(str);
  folly::StringPiece sp(str);
  sampleMethod(utf8Range); // works
  sampleMethod(sp); // works
  sampleMethod(str); // doesn't work

This diff hopes to fix this issue.

Reviewed By: ddrcoder

Differential Revision: D3221144

fb-gh-sync-id: dd6ec4d7790d4602dccb3b63a4861d358aed3608
fbshipit-source-id: dd6ec4d7790d4602dccb3b63a4861d358aed3608

Summary: same as D3156698, without changes in Cpp2Connection (which was the only real change in the diff)

Reviewed By: haijunz

Differential Revision: D3222792

fb-gh-sync-id: 245c7add837c0fc6d0bc84aa7d80b929ba2ce386
fbshipit-source-id: 245c7add837c0fc6d0bc84aa7d80b929ba2ce386

Summary: If we don't, then anywhere we include `glog/logging.h` after the portability header will get the `DECLARE_*` and `DEFINE_*` macros undefined -_-....

Reviewed By: mzlee

Differential Revision: D3220797

fb-gh-sync-id: 52907ddcd6b222fb1c6423034ea999eac5ce09ab
fbshipit-source-id: 52907ddcd6b222fb1c6423034ea999eac5ce09ab

Summary: This dependency is in the wrong order.

Reviewed By: knekritz

Differential Revision: D3224312

fb-gh-sync-id: 98d2c58b75cf5f16892d462ae1b877d06bce3faa
fbshipit-source-id: 98d2c58b75cf5f16892d462ae1b877d06bce3faa

Summary: Why not kill fbstring entirely? There are some legitimate use cases. For example, `folly::IOBuf` supports `moveToFbstring()` method which is impossible to implement with `std::string`.

Reviewed By: joeg, snarkmaster

Differential Revision: D3189410

fb-gh-sync-id: 9bb9090ca6012ac32ba9fb79041b26ec4888781f
fbshipit-source-id: 9bb9090ca6012ac32ba9fb79041b26ec4888781f

Summary:
Retire `BOOST_STATIC_ASSERT` in favor of `static_assert`.

`static_assert` is part of C++ now, so we don't need workarounds like `BOOST_STATIC_ASSERT` anymore.

Partially automated:

    hg grep -lw BOOST_STATIC_ASSERT | xargs perl -pi -e 's~\bBOOST_STATIC_ASSERT\(([^;]*)\);~static_assert(\1, "");~g'
    hg grep -lw 'boost/static_assert.hpp' | xargs perl -pi -e 's,^#include <boost/static_assert\.hpp>\n,,gm'

Caught most instances. Formatting and remaining instances addressed manually.

Reviewed By: meyering

Differential Revision: D3215944

fb-gh-sync-id: f4552d5d9bfc416ce283923abe880437a4d0cba5
fbshipit-source-id: f4552d5d9bfc416ce283923abe880437a4d0cba5

Summary: This assignment is unnecessary, because in `for` loop we **always** call `cloneOneInto` that would assign another IOBuf to that IOBuf.

Reviewed By: alikhtarov

Differential Revision: D3215861

fb-gh-sync-id: ad87b99848aaae79f0870d49e0474f1abf0f28e5
fbshipit-source-id: ad87b99848aaae79f0870d49e0474f1abf0f28e5

Summary:
Had this in another diff, but it caused too much test noise. So I've separated
it out on it's own.

Reviewed By: yfeldblum

Differential Revision: D3213605

fb-gh-sync-id: 9ebfcf8430da7c66a31868032a0cef1e616ffc58
fbshipit-source-id: 9ebfcf8430da7c66a31868032a0cef1e616ffc58

Summary:When dealing with universal references, std::move will move from
objects that are passed as lvalue references. Instead std::forward
should be used, which only moves from an object if it's passed
as rvalue reference.

Reviewed By: yfeldblum

Differential Revision: D3200402

fb-gh-sync-id: 14be071e8498dd64cb8b2583c0cc2dd383bfebb8
fbshipit-source-id: 14be071e8498dd64cb8b2583c0cc2dd383bfebb8

Summary:It's been awhile.

Still has intern URLs (#10943549) but I'll fix that separately.

Reviewed By: jsedgwick

Differential Revision: D3213245

fb-gh-sync-id: ff60193ff368deaac8ca233d4289f30d8f6bb223
fbshipit-source-id: ff60193ff368deaac8ca233d4289f30d8f6bb223