Fixing problems with is_bitwise_serializable

[sithhell]

The newly introduced switch to is_trivially_copyable introduced problems with
std::true_type/false_type vs boost::mpl::true_/false_. This patch is attempting
to fix those issues.

[hkaiser]

LGTM, thanks!

[K-ballo]

What was the problem?

[hkaiser]

What was the problem?

It was a mixup between mpl::bool_ and std::constant_variable<bool, ...>

[K-ballo]

Could you be more precise? There were a number of changes in place to work only with X::value, so that the actual type of the trait result would not actually matter.

[sithhell]

specifically it was hpx::util::tuple, hpx::parcelset::parcel::data and hpx::actions::detail::action_serialization_data.

[K-ballo]

That still doesn't tell me much. What was the problem? Why didn't the measures in place failed (the ones reverted in this PR), were there missing in certain places?
How do I reproduce the issue?

[sithhell]

There was nothing reverted in this PR. you can reproduce it by running hello_world on two localities. I used clang 3.8.0 with ubsan and boost 1.60.0. However, I just discovered that the problem still seems to exist when compiling everything with asan.

[K-ballo]

This PR reverts a bunch of std::integral_constant<bool, X::value> to just X again, which were introduced with the bitwise-serializable changes so to avoid std::true_type/false_type vs boost::mpl::true_/false_ problems.

I would like to know why those changes failed to avoid the issue this PR is solving. Did I miss those fixes somewhere? Which files and lines make calls that will pick the wrong overload without this patch?

[sithhell]

Actually, I am not convinced right now that this patch fixes the issue with the continuation serialization for good. However, the changes that you claim that got reverted are mainly because I changed all specializations of is_bitwise_serializable in the hpx codebase to return std::true_type/std::false_type so we don't need that rewrapping. As said in another comment, I encountered this problem again. However, I think this patch is valid anyway as it removed some inconsistencies wrt boost.MPL and std type_traits.

[K-ballo]

There should be no inconsistencies between Boost.MPL and std type_traits, the code is intended to handle both. If there are, it's a bug and it should be fixed.

That said, I think it's a good idea to keep the code simple by requiring std::true/false_type base characteristics. I originally started doing this migration, on the premise that if a user explicitly specialized the trait instead of using the macro it was their own fault. Then I hit cases like tuple, where the macro does not help users, and reverted those changes. I believe a proper fix would be to introduce another macro to work with templates, one that takes a bool constant and specializes the trait as needed.

[K-ballo]

This (and other similar changes) should just be hpx::traits::is_bitwise_serializable<T>, as the trait would be required to derive from std::integral_constant<bool, C> as other traits do.

[sithhell]

The changes made in this PR turned out to be a red herring. The commit that causes problems is f854314. We need to investigate further why this change caused problems like these: https://gist.github.com/sithhell/c5a21ae5267c53783d3899182659783d