Summary: these print as errors when compiling hhvm opensource

Test Plan: none

Reviewed By: tudorb@fb.com

FB internal diff: D1195649

Test Plan: build with -Wsign-compare, no warnings

Reviewed By: njormrod@fb.com

FB internal diff: D1193502

Summary:
Use compare_exchange_strong to update the previous time so that
there is no race.  This diff also adds microbenchmarks.

Test Plan: unit tests

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1191217

Test Plan: eyeballs

Reviewed By: hannesr@fb.com

FB internal diff: D1185813

Summary: Cleaning up some inaccuracies, adding just a little detail in a few places, and trying very hard not to get OCD about the commenting style.

Test Plan: still builds

Reviewed By: hannesr@fb.com

FB internal diff: D1184910

Summary: This is a better name

Test Plan: unit tests. fbgs shows no external usage of this.

Reviewed By: hannesr@fb.com

FB internal diff: D1184905

Summary: pulling the trigger

Test Plan: Unit tests. Wait for contbuild and dependent unit tests

Reviewed By: hannesr@fb.com

FB internal diff: D1184842

Summary: Somebody set us up the enum

Test Plan: Unit tests still build and pass. Will see if dependencies build and their unit tests pass. But I don't think anyone uses this outside of `Try` (they shouldn't anyway).

Reviewed By: hannesr@fb.com

FB internal diff: D1184839

Summary:
Usually we construct Try<T> as a result of execution of some functor.
And we need to treat void and non-void functors in similar way, but that requires different, yet similar pieces of code.

This diff simplifies future usage of Try.

Test Plan: compile only

Reviewed By: andrii@fb.com

FB internal diff: D1190296

Summary:
Add operator+, which returns a new Cursor pointing the specified number
of bytes ahead.  Cursor already implemented a += operator.

Also add == and != operators for checking to see if two cursors are
pointing to the same location.  Note that some derived cursor classes do
contain additional state, and we don't consider that state when
comparing for equality.  For instance, two Appenders pointing to the
same location will compare as equal, even if they are configured with
different growth parameters.  It seems like this is the behavior most
users will expect, but let me know if you have concerns about this.

Test Plan: Updated the unit tests to exercise the new operators.

Reviewed By: davejwatson@fb.com

FB internal diff: D1183537

Test Plan: Built folly on ubuntu 13.04 and 13.10

Reviewed By: davejwatson@fb.com

FB internal diff: D1190155

Summary: Will commit in tandem with D1171409.

Test Plan: built folly

Reviewed By: tudorb@fb.com

FB internal diff: D1189713

Summary: Was broken but didn't notice it in all the random test failures

Test Plan: fbmake runtests

Reviewed By: njormrod@fb.com

FB internal diff: D1189113

Summary:
* git mv
* codemod facebook::wangle folly::wangle
* Change 'runnable' to be a base class in wangle instead of thrift

Justification:
* std::future doesn't have then, whenall, etc.
* boost::future doesn't support executors

@override-unit-failures

Test Plan: contbuild and pray

Reviewed By: hans@fb.com

FB internal diff: D1185194

Summary: so we can still handle signals during global destruction. (d'oh)

Test Plan: unittests

Reviewed By: philipp@fb.com

FB internal diff: D1188159

Summary:
@mhorowitz got

*** Aborted at 1393267847 (Unix time, try 'date -d @1393267847') ***
*** Signal 11 (SIGSEGV) (0x0) received by PID 12652 (TID 0x7f59cbfff700), stack trace: ***
pure virtual method called
terminate called without an active exception
Entered fatal signal handler recursively. We're in trouble.

in a test, and no stack trace.

The first time we enter recursively (ie. the second time overall), try to dump
without symbolization. The next time, give up.

Test Plan: folly/experimental/symbolizer/test, ran crash with a modified dumpStackTrace to force it to enter recursively

Reviewed By: lucian@fb.com

FB internal diff: D1187942

Summary:
In looking at how people were using common/base/Random, I noticed
a number of issues with our current usage of random number generators

1) People would simply declare a RandomInt32 without seeding it. This
results in a predictable seed
2) We initialize a Mersenne Twister RNG from a single int32. This
causes us to have a more predictable starting sequence of numbers
3) People aren't consistently using thread-local RNGs
4) Many of the APIs lack consistency. For example random32 takes a
max parameter that is exclusive while uniformRandom32 uses inclusive
boundries

I'm hoping a better API can fix this. thread_prng implements the Generator
concept with result_type = int32. It isn't actually a random number generator,
but it uses a thread local to point to a real generator. An advantage
of this is that it can be used in existing APIs but that it doesn't expose
the implementation of the RNG via the header file. One thing that's a bit
weird about it is that if you copy the object across threads it could
cause an error.

The Random class provides utilities that take any type of random number
generator. This has the advantage of allowing the user to pass a RNG
meant for testing or a secure RNG based on /dev/random. Another advnatage
is if you're woried about the performance of TLS lookups, you can
cache a local thread_prng which memoizes the TLS lookup.

If available, we use a SIMD optimized MT API

Some open questions:

1) What functions should be in random
2) Should the default RNG be a 64 or 32 bit based RNG

Test Plan: Benchmark runs

Reviewed By: simpkins@fb.com

FB internal diff: D1181864

Summary:
Converting an enum class to a string fails with clang.
Adfinder clang build failure is http://ci-fbcode.fb.com:8080/builders/project/builds/146520/steps/build/logs/stdio
Our version of clang supports std::underlying_type so use that implementation instead.

Test Plan:
fbconfig -r folly && fbmake runtests (only failure is folly/experimental/symbolizer/test:symbolizer_test which failed before this diff)
fbconfig --clang folly/test:conv_test && fbmake runtests (fbconfig -r --clang folly fails and fbconfig --clang folly/test && fbmake has some unrelated compile errors)
Build adfinder with clang

Reviewed By: delong.j@fb.com

FB internal diff: D1178770

Summary:
The headers <ext/hash*> were being included but not used when
_LIBSTDCXX_FBSTRING is defined. They have been relocated to within the
appropiate header block.

Test Plan:
fbconfig -r folly && fbmake runtests_opt

copy FBString and Malloc into libgcc, then
tp2_build libgcc/4.8.1/gcc-4.8.1-glibc-2.17-fb

Reviewed By: pgriess@fb.com

FB internal diff: D1187345

Summary:
Iterators are not required to dereference into lvalues, so
taking the address of the dereferenced value of a general iterator
may cause a compile-time error.

This bug was observed when compiling clang-3.4. Clang uses a custom
iterator type when calling fbstring::replace, whose dereference operator
returns a char (instead of the 'expected' const char&).

FBString takes the address of the dereference in order to test if the
iterator is actually an iterator referencing its own data. This protects
the string from data trampling in certain cases. See the added test case
for an example.

For sequence containers, the standard specifies that supplying interal
iterators for such operations is forbidden. The standard also states
that the iterators passed into containers will be dereferenced at each
location exactly once. The standard (from by too-brief inspection) does
not specify either of these restrictions for strings, which I find odd.

As a compromise between safety and strict compliance, the offending code
is now only run when the iterator type is either fbstring::iterator or
fbstring::const_iterator. In these cases, we know that it is safe to
both dereference the iterator multiple times and to take its
dereference's address.

While fixing this error, I noticed that fbstring::replaceImpl was
public. It is now private.

Test Plan:
Added a new test case to FBStringTest.cpp.

fbconfig -r folly && fbmake opt && fbmake runtests_opt

Reviewed By: delong.j@fb.com

FB internal diff: D1185655

Summary:
- Unfortunately when D1152140 broke the Android build, which uses the
Bionic C++ standard library, and which Boost doesn't auto-detect. Deal
with this by manually picking namespaces for template specialization
based on #defines.

Test Plan:
- fbconfig -r folly/ unicorn/utils/ && fbmake runtests
- Build Liger on iOS and Android

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1154569

Blame Revision: D1152140

Summary: See docblock in CrontabSelector.h.

Test Plan: unit test

Reviewed By: agoder@fb.com

FB internal diff: D1181803

Summary:
Implicitly construct Range<To> from Range<From> if From is implicitly
convertible to To.

Explicitly construct Range<To> from Range<From> if To is (explicitly)
constructible from From.

Add special-cases for Range<char*>, Range<unsigned char*> similar to the
ones for Range<const char*>, Range<const unsigned char*>.

Test Plan: test added

Reviewed By: philipp@fb.com

FB internal diff: D1182999

Summary: See the block comment in date_time_utils.h -- the actual Cron code comes in later diffs.

Test Plan: unit tests

Reviewed By: agoder@fb.com

FB internal diff: D1181554

Summary: and doubles!

Test Plan: none really, will test later for now it compiles

Reviewed By: tudorb@fb.com

FB internal diff: D1175021

Summary:
Remove type_ (unused), pack flags in least significant bits of sharedInfo_.
sizeof(IOBuf) remains 56 bytes.

Test Plan: folly/io/test with -opt and -dbg; iobuf*_test with asan as well.

Reviewed By: simpkins@fb.com

FB internal diff: D1179993

Summary: as title

Test Plan: fbconfig folly/io/test/ && fbmake runtests

Reviewed By: simpkins@fb.com

FB internal diff: D1176922

Summary: We've intentionally eliminated support for gcc's old variadic macro syntax so as to bring our close in line with compatbile standards. This diff enables folly to build using warp.

Test Plan: built folly

Reviewed By: delong.j@fb.com

FB internal diff: D1176956

Summary:
- We need to be able to disable FOLLY_HAVE_WEAK_SYMBOLS via
-DFOLLY_HAVE_WEAK_SYMBOLS=0. Switch the #ifdef checks to #if.

Test Plan:
- fbconfig -r folly && fbmake runtests
- Build in fbobjc

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1150036

Summary:
Without this change, the sig-handling test's deliberate
invalid access would trigger an ASAN-abort, which differed
from the expected SEGV.  Skip this test when ASAN is enabled.
* folly/experimental/symbolizer/test/SignalHandlerTest.cpp: Include
CPortability.h for definion of FOLLY_SANITIZE_ADDRESS.
(SignalHandler) [FOLLY_SANITIZE_ADDRESS]: Provide a different
regexp to match the first line of output from an ASAN-enabled binary.

Test Plan:
fbconfig --sanitize=address --platform-all=gcc-4.8.1-glibc-2.17 \
folly/experimental/symbolizer/test:signal_handler_test \
&& fbmake --fast runtests \
&& fbmake --fast runtests_opt

Sample output, before this change: https://phabricator.fb.com/P5428975
(search down to first AddressSanitizer abort.
With this change, expect that test to pass.

Reviewed By: lucian@fb.com

FB internal diff: D1164768

Test Plan: contbuild

Reviewed By: philipp@fb.com

FB internal diff: D1164211

Summary:
This diff is a split from D1157286 for folly part;
adds a substract function which substracts a histogram data from another;
modifies some of the const specifiers in the Histogram class.

Test Plan: tested on the thrift perftest by adding x-th percentile latency stats

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1158270

Summary: Fix OS X compilation

Test Plan: compiled on OS X

Reviewed By: delong.j@fb.com

FB internal diff: D1163199

Summary:
scanHaystackBlock may read-overrun the needle.data() buffer by
up to 15 bytes, but that overrun will never cross a page boundary.
The fix is to turn off ASAN-checking for this function, but since
that attribute is accompanied by a "noinline" one (which conflicts
with the function's own "inline"), I have also removed the "inline"
attribute on both decl and defn.  That is a good thing, regardless:
these days, there are very few cases in which we should be trying to
tell the compiler to inline.

Test Plan:
Before, this would elicit an ASAN abort.  Now it passes 100%:

fbconfig --platform-all=gcc-4.8.1-glibc-2.17 --sanitize=address \
folly/test:range_test && fbmake runtests

Reviewed By: philipp@fb.com

FB internal diff: D1162982

Summary:
Rather than opening and closing Elf files every time we symbolize them, we open
the first time and cache.

We're using two caches: one for the signal handler (fixed size, slow, but
async-signal-safe) and one for exception tracing and general use.

Also, unrelated, removed two useless frames from the stack trace dump in the
signal handler.

Test Plan: tests added

Reviewed By: lucian@fb.com

FB internal diff: D1161444

Test Plan: fbconfig -r folly/experimental/test:eliasfano_test && fbmake runtests_opt

Reviewed By: lucian@fb.com

FB internal diff: D1161670

Summary:
Changing all the include paths following D1151911.
Depends on D1151911

Test Plan: contbuild

Reviewed By: ldbrandy@fb.com

FB internal diff: D1159003

Facebook:
Contbuild is mostly passed, remaining failures are unrelated. I'm confident other failures are unrelated.
@override-unit-failures

Summary:
At long last, promoting this out of experimental. Also, while I'm at
it, I've separated the tests and benchmarks into their corresponding parts.

Redirect headers provided.

Test Plan: Unit tests, contbuild.

Reviewed By: marcelo.juchem@fb.com

FB internal diff: D1151911

Summary:
NaN or INF is not allowed according to JSON specification.
This will cause problems when other places try to encode the output
of toJson with NaN or INF.
raise error when parsing object with NaN or INF to JSON.

Test Plan: manually test, raise error for object w/ NaN

Reviewed By: delong.j@fb.com

FB internal diff: D1143853

Summary: Since I don't want to pay the cost when we access array elements. If I did, I would just use Java.

Test Plan: fbconfig folly/test/ && fbmake runtests

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1158505