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

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