Summary:
D1261546 introduced regression in `sizeof(ConcurrentSkipList)`.
In case of `NodeAlloc = folly::SysAlloc`, size of an empty `NodeAlloc` struct
is 1 byte, due to the alignment requirements of the next field, it got
translated into wasting 8 bytes.

Test Plan: fbconfig -r folly/test && fbmake opt -j32

@override-unit-failures

Reviewed By: lucian@fb.com

FB internal diff: D1264730

Summary:
* folly/folly-config.h (FOLLY_HAVE_CONSTEXPR_STRLEN): Define to
zero when compiling with clang, since clang's strlen is not constexpr.

Test Plan:
Run this:
fbconfig --clang --with-project-version clang:dev folly/test && fbconfig dbg
and observe that the following no longer strikes:
folly/test/RangeTest.cpp:304:25: error: constexpr variable 'hello1' must be initialized by a constant expression

I also tried using clang-3.4 (the current default),
fbconfig --clang folly/test && fbmake dbg
with these results:
https://phabricator.fb.com/P8583443

Reviewed By: pgriess@fb.com

FB internal diff: D1262840

Summary: Fix make check.  Benchmark.cpp was included twice, eventfd doesn't exist anymore.

Test Plan: autoreconf -i; ./configure; make check on ubuntu

Reviewed By: pgriess@fb.com

FB internal diff: D1259706

Summary:
Automake complains there are two Malloc.cpp rules - rename one of them.

Facebook: Actually this file doesn't even build in fbconfig - is it still necessary?

Test Plan: autoreconf -i on ubuntu doens't fail

Reviewed By: pgriess@fb.com

FB internal diff: D1257372

Summary:
When all the variants I am dreaming of work, there's a little more than
100 tests generated.

Test Plan: fbmake runtests

Reviewed By: hannesr@fb.com

FB internal diff: D1258754

Summary: Now compiles in 18 seconds. Took two minutes before.

Test Plan: `fbmake runtests_opt`

Reviewed By: smith@fb.com

FB internal diff: D1243689

Summary:
Allow specifying `SimpleAllocator` to use for node allocation.
Added optimizations for arena allocators.

Test Plan: fbconfig -r folly/test && fbmake opt -j32

Reviewed By: soren@fb.com

FB internal diff: D1261546

Summary:
There is no reason to force heap allocation for
`ConcurrentSkipList`.

Test Plan: fbconfig -r unicorn/test && fbmake opt -j32

@override-unit-failures

Reviewed By: lucian@fb.com

FB internal diff: D1261183

Summary: For use with Thrift::Frozen, especially.

Test Plan: Unit tests

Reviewed By: philipp@fb.com

FB internal diff: D1255257

Summary:
Subtle bugfix to fbvector

Reproduction requirements:
- emplace into a vector at a non-end position
- the vector has enough capacity for the extra elements
- the value type's internal state is poisoned after a move

What should happen, explained by picture:

INITIAL SETUP

abc1234XY____
^
want to insert two elements here

FIRST STEP: uninitialized move-construction
x and y are initialized, but could be in an invalid state

abc1234xyXY__

SECOND STEP: move-assignment, in reverse order

abc123xy4XY__
abc12xy34XY__
abc1xy234XY__
abcxy1234XY__

What actually happens:
An indexing error causes the entire tail (##1234xy##) to be
move-assigned, instead of the intended head of the tail (##1234##).

If the data type's move operator does not invalidate its own data (i.e.
move is essentially a copy, as is the case with atomic types) then the
move assignment of ##y## onto ##Y## and ##x## onto ##X## is basically a
no-op. However, for types that do invalidate their own data when being
the source of a move (e.g. non-empty vectors and fbvectors), then the
end result will have bad data in place of ##X## and ##Y##.

Detection:
This bug has lain dormant for a while.

Very few people emplace into a vector, and those few who do could be
saved by using a copy-movable type like int.

The original test case did not use a data type which poisoned itself
after being the source of a move, so the tests did not notice any
oddities.

A new testsuite, which does poison itself, did notice.

Test Plan:
re-enable the test/stl_test mega-test. Run it. All tests
pass.

fbconfig -r folly && fbmake runtests_opt

Run fbvector through the new test suite (which initially caught the
error). It now passes.

Reviewed By: robbert@fb.com

FB internal diff: D1257258

Summary: These were required to build folly on OSX.

Test Plan: build

Reviewed By: davejwatson@fb.com

FB internal diff: D1256856

Summary:
There are two operations on `FutureObject` (the backing object that both `Future` and `Promise` front), which are not threadsafe currently. Those are `setContinuation` and `fulfil`. They're not threadsafe because they have a race condition between checking to see whether they should run the continuation and the other side making its modification. This diff introduces a `std::atomic_flag` variable to avoid the race and make these threadsafe.

NB Making `Future`/`Promise` threadsafe does not make this pattern safe:

f1.via(...).then(...).then(...)

(In a hypothetical world where `Future::via` is another name for `executeWithSameThread`)
There is a race between the future from `via` and the call of `then` (and between the first and second `then`s), so the `then`s could execute in the far thread as intended, or they could execute in the current thread (probably not what was intended). This diff does not solve that semantic problem of which thread this runs in. But it does make it safer, in that all those continuations will always execute, just maybe not in the thread you had intended.

You may ask what is the benefit if that semantic problem still exists? That's up for debate. I think the safety is worth it: at least everything a n00b throws at it will *work*. The question of thread semantics can iterate. If we end up with thread semantics that really don't need locks (e.g. maybe because we move to an Rx/Later style "launch" at the end of a chain) we can always toss this atomic.

How does this affect performance? I'm doing some experiments and going to write up my findings. Early results indicate that outlier performance is impacted but not by a lot, but don't count those chickens until I hatch them. Part of the reason for sending this diff out is to run windtunnel experiments.

Test Plan: tests, benchmark, close inspection

Reviewed By: davejwatson@fb.com

FB internal diff: D1241822

Summary:
TIMED_SYNCHRONIZED_CONST is acquiring a read-write lock but releasing a shared lock.  Chaos ensues.
@override-unit-failures

Test Plan: Add unit test, test times out before fix, passes after fix.

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1251518

Blame Revision: D327492

Summary:
Subprocess::communicate callbacks are level-triggered, which makes writing
"chatty" communication protocols difficult -- you often want to silence the
write callback until you read the expected message. Add
Subprocess::enableNotifications() for this purpose.

Test Plan: test added

Reviewed By: lucian@fb.com

FB internal diff: D1251564

@override-unit-failures

Summary: Add loopOnce() method which provides functionality similar to event_base_loop(base, EVLOOP_ONCE);

Test Plan: fbmake

Reviewed By: simpkins@fb.com

FB internal diff: D1249753

Summary: Utility is doing reverse of prettyPrint. This is a first sketch.

Test Plan:
1) We can reverse all tests from prettyPrint test and use for our function. For now I just reversed several of them
2) We can also test prettyPrint and prettyToDouble together by checking whether prettyToDouble(prettyPrint(X)) == X. This is implemented.

Reviewed By: marcelo.juchem@fb.com

FB internal diff: D1159879

Summary:
This should be standard compliant. `__PRETTY_FUNCTION__` seems
unnecessary, it just prints `basic_fbstring`, might as well use that and
simplify the code.

Test Plan:
`fbconfig --platform-all=gcc-4.8.1-glibc-2.17-fb folly/test`
`fbmake runtests_dbg`
`fbmake runtests_opt`

`fbconfig --platform-all=gcc-4.7.1-glibc-2.14.1 folly/test`
`fbmake runtests_dbg`
`fbmake runtests_opt`

`fbconfig --clang folly/test`
`...`

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1243670

Summary:
Change NULLs to nullptrs.

Facebook:
I was tired of seeing lint errors for NULL -> nullptr, so I
fixed it.

How: modified flint's tokenizer to output lines of the form

sed -i '__LINE__s|\<NULL\>|nullptr|g' __FILE__

for each NULL token encountered.

Ran the sed lines, restricted to filepaths with extensions
h,hpp,cc,cpp,tcc. Did not apply to FacebookUpdate, due to weird
formatting; hphp, to be done in a separate diff; payment, due to a large
number of generated text which didn't play well with my flow; and
memcache, which has lots of .h's that cannot contain nullptr's because
they are included from .c's.

@bypass-lint

Test Plan:
fbconfig -r common folly && fbmake opt && fbmake runtests_opt
^ of the 4k+ test cases, about two dozen are failing. Slightly more
failed in master than with my diff applied.

arc unit

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1234261

Test Plan: Unit tests

Reviewed By: marcelo.juchem@fb.com

FB internal diff: D1236630

Summary:
For proper rounding, and also so memOpInChunks doesn't try to mlock / munlock /
madvise / munmap in chunks smaller than the page size.

Test Plan: memory_mapping_test

Reviewed By: lucian@fb.com

FB internal diff: D1232153

Summary:
Let's double check that `small_vector` is doing the right thing. So
it doesn't just accidentally work.

Test Plan:
`fbconfig folly/wangle && fbmake runtests`
`fbconfig --clang folly/wangle && fbmake runtests`

Reviewed By: marccelani@fb.com

FB internal diff: D1231360

Summary: Moar c++11 features.  marccelani's comments in D1195393, but in a separate diff.

Test Plan:
contbuild
fbconfig thrift/lib/cpp/test/
fbmake runtests

Reviewed By: rajat@fb.com

FB internal diff: D1219158

Summary:
This implementation improves the performance of AsciiCaseInsensitive.
AsciiCaseInsensitive uses toupper, and it's slow.
Since toupper only works for ascii characters and this function does exactly the same thing over the range of [0..256), we can gain 3x performance here.

Test Plan: unit test and benchmark

Reviewed By: lucian@fb.com

FB internal diff: D1217596

@override-unit-failures

Summary: `std::async` doesn't play nicely with our clang. Replace it with `std::thread`.

Test Plan: `fbconfig --clang folly/wangle && fbmake runtests`

Reviewed By: marccelani@fb.com

FB internal diff: D1230197

Summary:
In a shared library, we're using whichever memory allocator the main program
uses, but we may still believe we're using jemalloc if we load libjemalloc.so
(because rallocm is defined). This means we'll pass to rallocm pointers that
were not allocated by jemalloc, which is bad.

Test Plan: tests added

Reviewed By: ngbronson@fb.com

FB internal diff: D1228483

Summary: So people can more easily write functions which take contiguous values from memory.

Test Plan: Unit tests

Reviewed By: tudorb@fb.com

FB internal diff: D1217809

Summary: Now we could use small_vector::max_size in constant expressions

Test Plan: unittest

Reviewed By: delong.j@fb.com

FB internal diff: D1224274

Test Plan: fbconfig -r folly/experimental/symbolizer && fbmake runtests_opt && fbmake runtests

Reviewed By: simpkins@fb.com

FB internal diff: D1224552

@override-unit-failures

Summary: Preparing to land the other diffs. No code changes here, just moving files around.

Test Plan: fbconfig bistro/common/cron/test bistro/common/cron/utils/test ; fbmake runtests

Reviewed By: yinwang@fb.com

FB internal diff: D1225159

Summary: sorted_vector_types were missing move inserts that come with std::map in c++11. This prevents me from using move iterators in folly::merge use case.

Test Plan: unit tests

Reviewed By: delong.j@fb.com

FB internal diff: D1223426

Summary:
std::merge() does not guarantee the ordering when equal elements belong in two ranges(comparator(it_a, it_b) == comparator(it_b, it_a) == 0). For maps, it is important that we can specify the ordering (see array_merge in php, where we guarantee which array's value will be present in the output if a key is present in both inputs).

Also removes folly::merge that is specfic for sorted_vector_map since this will not be needed. NOTE: I expect this to break feed, will fix in a separate non-folly diff.

Test Plan: This implementation is directly ripped from cppreference.com, but unit tests added none-the-less. Specifically, one is added where the output is a std::map to demonstrate its usefulness.

Reviewed By: delong.j@fb.com

FB internal diff: D1223401

@override-unit-failures

Summary:
The signature of insert(hint, const val& v) is wrong. It should return an iterator, not pair<iterator, bool>. This breaks std::inserter, making it impossible to use this for std::merge. I plan to create folly::merge (std::merge with stronger semantics when equal values are present in the two input ranges), so I need this fixed.

Given that the documentation claims this is a "drop in replacement" for std::map, I figure we should fix this.

Test Plan: reran unit tests

Reviewed By: delong.j@fb.com

FB internal diff: D1223396

Summary:
Feed spends a non trivial amount of time merging two sorted_vector_maps. Writing code for this efficiently is actually a little tricky, and its much easier to maintain the simpler code. This adds merge() to folly so that its easy for feed and fast. Benchmarks with large input sizes show this is a gigantic win (moving from O(n^2) to O(n).

Test Plan: unit tests, benchmark

Reviewed By: delong.j@fb.com

FB internal diff: D1221725

@override-unit-failures

Summary:
Define a value_type for folly::dynamic to make arrays work with
folly::gen::from.

Test Plan:
- added new unit test
- fbconfig folly/test && fbmake runtests

Reviewed By: tjackson@fb.com

FB internal diff: D1216358

Summary:
Move the minimum amount of stuff and still have everything compile.  Would like to move TAsyncSocket/ServerSocket/SSL/UDP eventually, but not this round.

thrift async is used very widely now: thrift, proxygen, newer mysql async interface, even trying it out in memcache.  A common complaint is that it doesn't get wide enough notice under thrift/, so let's move it to folly/.  After moving TAsyncSocket, both HHVM and proxygen could avoid a dep on thrift as well.

Changes:
* mv files to folly/io/async
* remove 'T' prefix on classes/filenames
* change namespace to 'folly'
* remove any thrift references.

Tried this before in D470080, this time doesn't attempt to abstract libevent

@override-unit-failures

Test Plan:
fbconfig -r thrift; fbmake dev.
Will iterate on any other contbuild failures

Reviewed By: pgriess@fb.com

FB internal diff: D1195393

Summary:
Let's make sure that boost version is intented to mean exactly
the same as `std::is_trivially_copyable` (see 9 [class] / 6) to avoid any
confusion (current boost path is more close to
`std::is_trivially_copy_constructible` than to
`std::is_trivially_copyable`;  UPD: unfortunately, old versions of boost
don't support `boost::has_trivial_move_constructor` and friends, so I
can't completely mimic `std::is_trivially_copyable` here).

As mentioned in the original comment, `__has_trivial_copy` returns 1 in
case of deleted copy ctor in clang (contradicts 12.8 [class.copy] / 13 +
8.4.2 [dcl.fct.def.default] / 4), which makes `FOLLY_IS_TRIVIALLY_COPYABLE`
accept `std::unique_ptr<>`; using `boost::has_trivial_destructor` would
at least save us from the problems in this case.

Alternative "solution" may be to rename `FOLLY_IS_TRIVIALLY_COPYABLE` to
`FOLLY_IS_TRIVIALLY_COPY_CONSTRUCTIBLE`, and make sure
`folly::small_vector` won't call dtor when memcopies the data around.

Test Plan: fbconfig --clang folly/test:small_vector_test && fbmake runtests_opt (fails in trunk, passes with this diff)

Reviewed By: pgriess@fb.com

FB internal diff: D1216158

Summary: Title.  Note that this is a no-op with default parameters because folly::toAppend(double, &dest) calls folly::toAppend(double, &dest, DtoaMode, numDigits) with DtoaMode = SHORTEST and numDigits = 0.

Test Plan: Tested new functionality in D1212547.

Reviewed By: kelarini@fb.com

FB internal diff: D1212617

Summary:
The Cursor class didn't provide a copy constructor accepting a
"const Cursor&".  The existing constructor only accepted references to
non-const Cursor.

This updates the constructor to also accept "const Cursor&".  I also
made the template parameter checking more strict, so that it only
accepts other CursorBase classes.  This prevents the compiler from
thinking that a Cursor can be constructed from any other possible type
when performing overload resolution.

Test Plan: Ran all of the folly cursor tests.

Reviewed By: davejwatson@fb.com

FB internal diff: D1208428

Summary:
This extends the fixed version of folly::split to support numeric types
as targets in addition to string pieces. I was almost certain this was
already possible when I recently reviewed some code that did

folly::StringPiece source, target, strFrequency;
int frequency;
if (folly::split('\t', line, source, target, strFrequency) &&
(frequency = folly::to<unsigned int>(strFrequency)) > 0)

and was about to suggest changing the above into:

folly::StringPiece source, target;
int frequency;
if (folly::split('\t', line, source, target, frequency) && frequency > 0)

I double checked and saw that only splitting to string pieces was supported.

In the meantime I came across this pattern again and decided to just make
it work because it's really convenient.

The implementation should be fully backwards compatible.

Test Plan:
- New unit tests
- fbconfig -r folly && fbmake runtests
- Applied to github release, ./configure && make check

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1187004