Summary:
The code to convert signed 128-bit integer values to strings would trigger
undefined behaviour when trying to convert the most negative possible value,
as exposed by the new test cases.

The fix is to negate the corresponding unsigned value (just like it's already
done for the 64-bit code).

This change doesn't have any performance impact.

Reviewed By: yfeldblum

Differential Revision: D3455817

fbshipit-source-id: 83782992324f443789760a0e61cd9b889faaf317

Summary:
In preparation for some changes to the integer-to-string conversion
code, this change adds, this adds some more benchmarks, and attempts
to update the existing ones to be less prone to the optimizations
where the compiler already knows about the constant values being
passed in.

There also were a couple of flaws in the existing benchmarks, where
instead of computing the value to be converted from a start value
and the loop counter, it rather added the (constant) total iteration
count to the value, ending up with a constant. But, worse than just
using a constant, the code that was trying to evaluate the cost of
converting a single-digit would generally end up computing the cost
of a five-digit number, which resulted in the benchmarks showing
identical figures regardless of the number of digits for small digit
counts.

The change also adds benchmarks for positive/negative signed integers
and 128-bit integers.

Reviewed By: yfeldblum

Differential Revision: D3455815

fbshipit-source-id: a20821c7d460bc05453655d0c848a0c9a47520fd

Summary:
Due to the definition of how floating point values convert to boolean,
the check for undefined behaviour wouldn't work correctly. The result
of (1 - 0.9999999999999999) would yield 0 when converted to an integer,
but yields true (1) when converted to a boolean.

As all floating point values can thus be converted to boolean without
triggering undefined behaviour, this change overloads checkConversion()
appropriately

Reviewed By: yfeldblum

Differential Revision: D3477368

fbshipit-source-id: 5b2aeb6194629cf3a6195529aac2362c0d35799c

Summary:
A bit of tidying up:

- Remove unused digit1 / digit2 arrays
- Remove unused MaxString<bool>
- Move MaxString<> entirely to Conv.cpp, as it's not used in Conv.h
- Extend anonymous namespace in Conv.cpp
- Sort headers in Conv.h

Reviewed By: yfeldblum

Differential Revision: D3433767

fbshipit-source-id: 224a68f22505c0f2014ac376154d004eca1658a9

Summary:
This change fixes a case of undefined behaviour when converting between
floating point and integral values using folly::to<>. Undefined behaviour
is triggered when a floating point value is cast into an integral value
that cannot represent the source value. This happens in both cases,
float-to-int and int-to-float conversion, with folly::to<> due to the
check for loss of precision.

The new test cases expose the undefined behaviour.

The fix is a series of extra checks, the majority of which will only
kick in if the value to be converted is close to the boundary of the
range of the target type. These checks ensure that the conversion will
only be performed if the source value is within the range representable
by the target type.

The extra checks /will/ make the code slower. However, a later change
in this series, which refactors the implementation of folly::to<>, will
restore some of the performance.

Reviewed By: yfeldblum

Differential Revision: D3433757

fbshipit-source-id: 43495d18f831206ef48f74332663263d789a4f8a

Summary:
To avoid error while running ./configure command:
 ./configure: line 18976: AX_BOOST_CHRONO: command not found

Besides in my Fedora 23 the following error ocurred when not linked with -lboost_chrono running 'make check':
/usr/bin/ld: SynchronizedTest.o: undefined reference to symbol 'boost::chrono::steady_clock::now()''
/usr/lib64/libboost_chrono.so.1.58.0: error adding symbols: DSO missing from command line
Closes https://github.com/facebook/folly/pull/426

Differential Revision: D3457939

Pulled By: elliottneilclark

fbshipit-source-id: ec7a8d30d4812f197e2813e611cde0e33eab680a

Summary:
This adds a couple of new benchmarks that will be used as a basis to
check the performance of a series of upcoming changes to folly::to<>.

It exercises both successful and unsuccessful conversion paths for
string-to-anything, int-to-int, int-to-float, float-to-int, and pair-
of-pointers-to-int conversions.

The following table only shows the newly added benchmarks:

  ==============================================================
  folly/test/ConvBenchmark.cpp                time/iter  iters/s
  ==============================================================
  stringToBoolNumClassic                        12.76ns   78.37M
  stringToBoolNumClassicError                    3.19us  313.37K
  stringToBoolStrClassic                        17.92ns   55.79M
  stringToBoolStrClassicError                    3.21us  311.73K
  --------------------------------------------------------------
  stringToFloatNumClassic                       32.96ns   30.34M
  stringToFloatNumClassicError                   2.73us  366.49K
  stringToFloatStrClassic                       37.37ns   26.76M
  stringToFloatStrClassicError                   2.87us  348.81K
  stringToDoubleNumClassic                      31.30ns   31.95M
  stringToDoubleNumClassicError                  2.69us  371.26K
  stringToDoubleStrClassic                      37.67ns   26.54M
  stringToDoubleStrClassicError                  2.87us  348.97K
  --------------------------------------------------------------
  stringToCharSignedClassic                     16.71ns   59.85M
  stringToCharSignedClassicError                 3.87us  258.50K
  stringToCharUnsignedClassic                   15.49ns   64.54M
  stringToCharUnsignedClassicError               2.73us  366.88K
  stringToIntSignedClassic                      21.26ns   47.03M
  stringToIntSignedClassicError                  3.94us  253.82K
  stringToIntUnsignedClassic                    17.93ns   55.79M
  stringToIntUnsignedClassicError                2.72us  367.93K
  stringToLongLongSignedClassic                 34.63ns   28.88M
  stringToLongLongSignedClassicError             3.94us  253.52K
  stringToLongLongUnsignedClassic               51.04ns   19.59M
  stringToLongLongUnsignedClassicError           2.73us  366.58K
  --------------------------------------------------------------
  ptrPairToCharSignedClassic                     5.16ns  193.62M
  ptrPairToCharSignedClassicError                3.56us  280.99K
  ptrPairToCharUnsignedClassic                   2.43ns  411.44M
  ptrPairToCharUnsignedClassicError              2.63us  380.42K
  ptrPairToIntSignedClassic                      6.99ns  143.09M
  ptrPairToIntSignedClassicError                 4.08us  245.27K
  ptrPairToIntUnsignedClassic                    4.25ns  235.09M
  ptrPairToIntUnsignedClassicError               2.70us  370.55K
  ptrPairToLongLongSignedClassic                12.16ns   82.27M
  ptrPairToLongLongSignedClassicError            4.06us  246.17K
  ptrPairToLongLongUnsignedClassic              29.13ns   34.33M
  ptrPairToLongLongUnsignedClassicError          2.71us  369.33K
  --------------------------------------------------------------
  intToCharSignedClassic                       405.02ps    2.47G
  intToCharSignedClassicError                    2.10us  475.11K
  intToCharUnsignedClassic                     303.79ps    3.29G
  intToCharUnsignedClassicError                  2.10us  475.18K
  intToIntSignedClassic                        405.02ps    2.47G
  intToIntSignedClassicError                     1.99us  501.60K
  intToIntUnsignedClassic                      405.03ps    2.47G
  intToIntUnsignedClassicError                   2.09us  478.47K
  --------------------------------------------------------------
  intToFloatClassic                            545.11ps    1.83G
  intToFloatClassicError                         1.67us  599.38K
  --------------------------------------------------------------
  floatToFloatClassic                          759.47ps    1.32G
  floatToFloatClassicError                       6.45us  154.98K
  --------------------------------------------------------------
  floatToIntClassic                            637.82ps    1.57G
  floatToIntClassicError                         1.92us  520.16K
  ==============================================================

Reviewed By: yfeldblum

Differential Revision: D3433745

fbshipit-source-id: 6ab1ede32c07e7fc29b982e8705ecc0138fa6384

Summary:
Ubsan complains when overriden method is called from ctor:
```
0x000000b04d40: note: object is of type 'folly::detail::SingletonHolder<XYZ>' 00 00 00 00  08 50 c3 8d da 7f 00 00  e8 4f c3 8d da 7f 00 00  18 0d 4c b4 da 7f 00 00  a0 16 90 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'folly::detail::SingletonHolder<XYZ>'
```

called from `folly::SingletonVault::registerSingleton(folly::detail::SingletonHolderBase*)`

Reviewed By: ot

Differential Revision: D3462037

fbshipit-source-id: 6df283dd53df42d5d318990f60aba370ceed6395

Summary: This is needed to work around a limitation in MSVC's SFINAE support.

Reviewed By: yfeldblum

Differential Revision: D3271292

fbshipit-source-id: 88052beaa97a297c6eb3eb5047c8fed48c8155af

Summary: Add folly locks to the HasLockUnlock struct so that they can be used inside Synchronized. acquireReadWrite() and releaseReadWrite() functions are added to each lock class so that their .lock and .unlock methods are accessible by Synchronized. These changes allow an extremely basic level of compatibility for the purpose of running benchmarks and so compatibility with dual_locking, etc. have not been tested.

Reviewed By: simpkins

Differential Revision: D3434621

fbshipit-source-id: d55cffbb1eccaf23645384b9a41f85c5df593ffe

Summary:
[Folly] Wrappers for some of OpenSSL's crypto hash functions.

Wraps some of the OpenSSL crypto hash functions with variants that take `ByteRange` for input and `MutableByteRange` for output, and also variants that take `const IOBuf&` for input as well.

These are a bit nicer to use than passing pointers and lengths separately.

Reviewed By: ivmaykov

Differential Revision: D3434562

fbshipit-source-id: 3688ef11680a029b7664ac417a7781e70f9c6926

Summary:
We were calling ourself, which MSVC correctly identified:
```
warning C4717: 'folly::sorted_vector_set<int,`anonymous namespace'::less_invert<int>,std::allocator<int>,void>::insert': recursive on all control paths, function will cause runtime stack overflow
```

Just add an explicit `std::move` in to solve the problem.

Reviewed By: yfeldblum

Differential Revision: D3447922

fbshipit-source-id: 803f79510b3dbfeea32a9629238448f69f5b78dc

Summary:
[temp] (14)/6:
> A function template, member function of a class template, variable template, or static data member of a class template shall be defined in every translation unit in which it is implicitly instantiated (14.7.1) unless the corresponding specialization is explicitly instantiated (14.7.2) in some translation unit; no diagnostic is required.

`-Wundefined-var-template` warns on any implicit instantiations that are needed but could not be performed because the definition is not available. In particular, for valid code, this warns on templates/temploids which have their definition and all relevant explicit instantiations tucked away in some source file (but for which no explicit instantiation declarations are provided in the relevant header file) - used a few times in folly. This seems a bad style, the static data member template should either be defined in the header file or should be explicitly instantiated in each .cpp file.

Reviewed By: igorsugak

Differential Revision: D3270439

fbshipit-source-id: e8cdb0452c2f6240a348b93cdbf9975813f27bfe

Summary: This mass of conditions is completely pointless, because GCC has supported the standard intrinsics since at least 4.4.7, which is as far back as godbolt lets me test.

Reviewed By: yfeldblum

Differential Revision: D3373640

fbshipit-source-id: 619e971034db9249a9b312d18870bc7e4d579d50

Summary:
[temp] (14)/6:
> A function template, member function of a class template, variable template, or static data member of a class template shall be defined in every translation unit in which it is implicitly instantiated (14.7.1) unless the corresponding specialization is explicitly instantiated (14.7.2) in some translation unit; no diagnostic is required.

`-Wundefined-var-template` warns on any implicit instantiations that are needed but could not be performed because the definition is not available. In particular, for valid code, this warns on templates/temploids which have their definition and all relevant explicit instantiations tucked away in some source file (but for which no explicit instantiation declarations are provided in the relevant header file) - used a few times in folly. This seems a bad style, the static data member template should either be defined in the header file or should be explicitly instantiated in each .cpp file.

Reviewed By: igorsugak

Differential Revision: D3270439

fbshipit-source-id: bf305fde3af575a265d65a0ae0bf95db5597587f

Summary: Added method to enable server support for a specific elliptic curve encryption algorithm.

Reviewed By: siyengar

Differential Revision: D3432860

fbshipit-source-id: 078531eead48ea156a68a109f8a62dc4907ac1ec

Summary: Fix bug for passing null pointer to memchr function, which requires the first argument to never be null.

Reviewed By: luciang

Differential Revision: D3432130

fbshipit-source-id: 419924dd214d9f641d3d46335dae6abbe44ca751

Add constructor for MultiLevelTimeSeries class that uses initializer_list and add stat methods that uses duration as a parameter.

Summary: Introduce a constructor that takes in an initializer list of 'TimeType' objects for the durations. New methods for sum/avg/rate/count/countrate are created with a 'TimeType' parameter - this makes it possible to call these methods using the duration that specifies the level. Previously, these methods could only be called using the index of the level in the levels_ vector. These methods first do a linear scan through levels_ using the method getLevelsByDuration to find the corresponding index, and then perform the function they specify on the level.

Differential Revision: D3414343

fbshipit-source-id: 8e1fcc16fd013d0b8b855a1eebbeff417e945b07

Summary: It's useful to be able to build & run the benchmark.

Differential Revision: D3433731

fbshipit-source-id: c37bd5be3da0f89d4792747857d2e7548aea08ba

Summary: The iOS sdk adds `clock_gettime` support.

Reviewed By: clementgenzmer

Differential Revision: D3427621

fbshipit-source-id: 534276ba1e0ade185e3af0665f419f3c51d3f980

Summary: Since loopKeepAlive() is always used from the EventBase thread, there's no need for the overhead of an shared_ptr (and therefore, an atomic ref counter); we can get away without thread safety. This also allows us to discard the (sometimes incorrect) optimization of not returning a handle when it appears the loop will continue running anyways

Reviewed By: andriigrynenko

Differential Revision: D3375503

fbshipit-source-id: 474e4fcf992bdc4fcca9370d3c57bdcc4e042386

Summary: The iOS sdk adds `clock_gettime` support.

Reviewed By: clementgenzmer

Differential Revision: D3427621

fbshipit-source-id: fcd3022c5ea05ceb8e289fbeb1ae845155d2dea9

Summary:
I had a crash bug where an `EventBase` handler called a function, which tried to use the thread's EventBase as if it were its own:

```
auto evb = folly::EventBaseManager::get()->getEventBase();
// schedule work on evb, which calls evb->terminateLoopSoon() on completion
evb->loopForever();
```

This ended up invoking the `event_base_loop()` reentrantly, and corrupting the heap in a hard-to-debug way.

Reviewed By: djwatson

Differential Revision: D3408155

fbshipit-source-id: b8855aa3b390fa33e032ab295d386122d2cb872a

Summary:
Boost 1.61 removes the `boost::context::fcontext_t` type
which Folly Fibers depends on.

This makes the Fibers library conditional on a working `fcontext_t`,
so Folly will build (just without Fibers) if it's not present.

Depends On D3419638

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

Reviewed By: Orvid

Differential Revision: D3420097

fbshipit-source-id: 876f8f76a2d0dda4ce5085c27875ab6aaa7b86c0

Summary: We only need fcontext.hpp, so let's include it directly. all.hpp includes other headers, which use thread-locals (doesn't work with our OSX build).

Reviewed By: igorsugak, bhamiltoncx

Differential Revision: D3419638

fbshipit-source-id: b4fa1bd14454bcd75eaece52c398ac6510273773

Summary:
Added the class `DeterministicMutex`, a wrapper for `std::mutex`, in `folly/test/DeterministicSchedule.h`. Added a test to `folly/test/DeterministicScheduleTest.cpp` to test the correct behavior of `DeterministicMutex` functions and that deterministic schedule is able to detect race conditions that involve `DeterministicMutex`.

Note: Bootcamp task

Reviewed By: djwatson

Differential Revision: D3412579

fbshipit-source-id: c12861c4ec1cfeadcef027be4513e8e4cb7e0176

Summary:
This is needed in order to be able to use folly::Try<> with folly::to<> for
non-throwing conversions.

Reviewed By: meyering

Differential Revision: D3411003

fbshipit-source-id: 1f20e7871b9cedda2b35527dac70381579abd708

Summary:
I would switch these to just use the intrinsic functions, but GCC 4.8 doesn't support them.
MSVC supports the intrinsics, which is the primary reason for the switch.

Reviewed By: philippv

Differential Revision: D3278901

fbshipit-source-id: 60103ac7cf7ddfb529f65f4aadc687dbdaf423a1

Summary:
This diff is part of a string of changes that is getting `HHWheelTimer` to use standard smart pointers.

D2617966 is being reverted. The `DestructorGuard` that was added for safety is not possible without intrusive reference counting.
That means that the `count_` (of pending callbacks) will still be correct, but there will be nothing to check it against. Because of that, I removed the assertions to make sure that the count of pending callbacks matches the count of active guards. Anyway, there were already ways to defeat that test, such as by creating a `DestructorGuard` from any client code.
As long as the assertions are gone, the `cancelAll` can be moved to the destructor. It only ever got run when `destroy` was called and `count_` was `0`, which means that `~HHWheelTimer` was also going to get called at the same time.

Reviewed By: djwatson

Differential Revision: D3349303

fbshipit-source-id: 433fa6605ee9921833328e2f82bd07b2e17e42c5

Summary: Closes https://github.com/facebook/folly/pull/421

Reviewed By: yfeldblum

Differential Revision: D3413832

Pulled By: elliottneilclark

fbshipit-source-id: 7af1462c250c8d6b5d6f5dfcb3f3117dff7877c9

Summary: Fix a data race found by TSAN in folly::fibers::Baton by changing a memory_order_relaxed to memory_order_acquire.  Nathan Bronson says that TSAN is correct and the C++ memory model requires _acquire here.

Reviewed By: andriigrynenko

Differential Revision: D3412519

fbshipit-source-id: bd0043b41d145e689a97fc7ef47aa6e116ea9194

Summary: parse command line flags to pick up -json flag

Reviewed By: mzlee

Differential Revision: D3405794

fbshipit-source-id: e2d216c74f04c15d7470c70abfc2bd25c2ceda98

Summary:
Without this const_cast, it's impossible to insert anything into an
AHA with a const mapped_type, making it effectively useless.

Reviewed By: yfeldblum

Differential Revision: D3405687

fbshipit-source-id: 3ecba19e0e92661c2c537c747b4927176104939f

Summary:
Declare size() to return a constexpr value, so it can be called on constexpr
Range objects.

This unfortunately does drop the existing assert() check, due to a gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71448

Reviewed By: lbrandy

Differential Revision: D3394612

fbshipit-source-id: 77ea3b961dc323a39dea6f0e5850f9a311210d09

Summary: The comment was right about the packed attribute not liking private members, so pack `PackedSyncPtr` to get GCC to pack structs containing it correctly.

Reviewed By: yfeldblum

Differential Revision: D3402936

fbshipit-source-id: 11d9def132d5dedf04b0e263c379cac339a52fa3

Summary:
Add new versions of hexlify() and unhexlify() that directly return a
std::string, similar to the helper functions that already exist for humanify()
and backslashify().

The function signatures for these helpers are different than the humanify() and
backslashify() helpers--these functions always accept StringPiece or ByteRange
arguments.  This allows them to easily accept "const char*" arguments, without
having to convert the arguments to a std::string.  (I think we probably should
fix the humanify() and backslashify() helpers to be similar in a separate
diff.)

Reviewed By: yfeldblum

Differential Revision: D3403863

fbshipit-source-id: a2df49d5857e1d34caac3d78283dc293f4ef1ab6

Reviewed By: ldemailly

Differential Revision: D3402550

fbshipit-source-id: 3de47c569868545c3861dab9a7b244ed8fb1fadf

Summary:
Inteded use case is to write tracing code in common components that can adjust its behavior to the current observer. E.g.
  auto* observer = FiberManager::getUnsafe()->getObserver();
  if (auto* specific_observer = dynamic_cast<SpecificObserver*>(observer)) {
    specific_observer->set_fiber_name(...);
  }

Reviewed By: andriigrynenko

Differential Revision: D3392890

fbshipit-source-id: 284b4964bbb17e9a081779b870af68e8f1a81634

Summary:
This adds TFO support to AsyncSSLSocket which
uses the support for TFO from AsyncSocket.

Because of the way AsyncSSLSocket inherits from
AsyncSocket it is tricky.

The following changes were made:
1. Openssl internally will treat only errors with return
code -1 as READ_REQUIRED or WRITE_REQUIRED errors. So this
diff changes the return value of the errors in the TFO fallback
cases to -1.

2. In case we fallback after SSL_connect() to a normal connect,
we would have to restart the connection process after connect
succeeds. To do this this overrides the connection success callback
and restarts the connection before sending the callback to AsyncSocket
because sometimes callbacks might synchronously call sslConn() in the
normal connect cases.

3. Delegated bioWrite to call sendSocketMessage instead of sendmsg directly.

Reviewed By: djwatson

Differential Revision: D3391735

fbshipit-source-id: 61434f6de4a9c3d03973c9ab9e51eb49e751e5cf

Summary:
This defines the macro `FOLLY_SANITIZE_THREAD`, similar to `FOLLY_SANITIZE_ADDRESS`.

Note that gcc *just* landed support for the `__SANITIZE_THREAD__` macro two weeks
ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354

Reviewed By: igorsugak

Differential Revision: D3389021

fbshipit-source-id: df6497a7741657c297ee812ed07cbae102b6810d