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

Summary:
Add setPort() method to URI class for easy port replacement in
URIs.

Facebook:
Perform port replacement in WriteProcessor.cpp in a way that
supports URI schemes. Add setPort() method to URI class to replace
the port number in the authority portion of the URI.

Test Plan: Test in debugger for dfsrouter changes.

Reviewed By: tudorb@fb.com

FB internal diff: D1209120

Summary: Allow disabling ASan for `folly::Bits`.

Test Plan: [fb-only]

Reviewed By: soren@fb.com

FB internal diff: D1208584

Summary: This should be 'docs' not 'doc'. Too bad now it exceeds 80 chars :(.

Test Plan: n/a

Reviewed By: simpkins@fb.com

FB internal diff: D1209738

@override-unit-failures

Summary:
Support `.then(&static_function)`, `.then(&static_member_function)`, `.then(&Class::static_member_function)`, `.then(instance, &Class::member_function)` in Wangle.

C++ does not allow `.then(instance, &member_function)`, sadly.

This implementation just creates the closure for you and defers to the existing `then` implementations.

Test Plan: Added a test.

Reviewed By: hans@fb.com

FB internal diff: D1204954

Summary: Seems like there is no real need to restrict permissions by default?

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

@override-unit-failures

Reviewed By: tudorb@fb.com

FB internal diff: D1205527

Summary:
I guess they sneaked in when testing.

Also remove an `EXPECT_NE` that depended on `std::move` actually moving.

Test Plan: All the tests.

Reviewed By: hans@fb.com

FB internal diff: D1204971

Summary:
Need to use `std::decay` to actually support the universal reference.

The futures are moved in, and invalidated.

Test Plan: Test; does not compile before.

Reviewed By: hans@fb.com

FB internal diff: D1199841

Summary: Replace random_device/mt19937 with folly/Random to increase hygiene of using Random

Test Plan:
For each file is changed, fbmake -opt is run; except one file: stealing_test.cc, since the TARGETS file is not under the path.
All fbmake are successfully passing

Reviewed By: bmaurer@fb.com

FB internal diff: D1199483

Blame Revision: v1

Summary: Don't need to keep the old futures around.

Test Plan: `FutureTest.cpp`

Reviewed By: hans@fb.com

FB internal diff: D1197360

Summary: Fix off-by-one affecting benchmark numbers in folly/io.

Test Plan:
$ fbconfig -r folly/io/test
$ fbmake --fast opt
$ _build/opt/folly/io/test/iobuf_cursor_test --benchmark
$ _build/opt/folly/io/test/iobuf_network_bench --benchmark

Reviewed By: simpkins@fb.com

FB internal diff: D1199679

Blame Revision: D344018

Summary:
Facebook:
Moving from Dex.
Transliteration from whatever wiki format Dex uses to Markdown
Some minor corrections/additions.

Test Plan: Pasted into a private gist and it looks reasonable on github.

Reviewed By: davejwatson@fb.com

FB internal diff: D1199510

Summary:
Tao neesd a way to wrap its c-style async apis with Later. Although my comments suggest that you can do this, it turns out I never got around to implementing it. Well, here is the implementation.

Basically, we supply the callback to the pre-existing api, and that callback will fulfill a promise that is used internally within Later. This is thread safe because the async call is not made until the starter is fired, and we can use the future immediately for chaining then() calls.

Test Plan: unit test

Reviewed By: hannesr@fb.com

FB internal diff: D1197721

Summary: trunk fails to compile under clang: https://phabricator.fb.com/P6426175

Test Plan: ran some benchmarks and checked output

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1192933

Summary:
folly/Benchmark.cpp:427:9: error: logical not is only applied to the left hand side of this comparison
if (!strcmp(get<1>(benchmarks[i]), "-") == 0) {

Since the `!` binds to `strcmp`, removing both the `!` and the `== 0`
should be equivalent.

Reviewers of diff that introduced this line: D490324

Test Plan: I compiled `tao/client` with/without this diff.

Reviewed By: delong.j@fb.com

FB internal diff: D1196452

Blame Revision: rFBCODE6f5eea5fcd23044a5c579b040bf45d17006b4adf

Summary:
- Some users of Folly don't want to pull in the entire library just to
use one feature (e.g. folly::to<T>). Throw those users a bone by
breaking Folly up into a few discrete chunks: :uri, :range, :string,
:format, etc. Leave the top-level :folly target alone so that existing
users don't have to be changed.
- Update some Thrift and Proxygen users to use the more granular
targets.

Test Plan: - Phabricator contbuild

Reviewed By: tudorb@fb.com

FB internal diff: D1192765

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