update FOLLY_IS_TRIVIALLY_COPYABLE
authorPhilip Pronin <philipp@fb.com>
Wed, 12 Mar 2014 08:00:52 +0000 (01:00 -0700)
committerDave Watson <davejwatson@fb.com>
Tue, 18 Mar 2014 17:01:38 +0000 (10:01 -0700)
commite22f0a67786b71aa5d73bfe1b3cd30f9ba329356
tree231bdf11bea921a5d359f072f4aee2feedc83f60
parent46526221f2c4483830b62bd13fadf7caeea4dfdb
update FOLLY_IS_TRIVIALLY_COPYABLE

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
folly/Portability.h
folly/test/small_vector_test.cpp