Here is the test result:
100% tests passed, 0 tests failed out of 1103
Here are the details of the source workarounds:
1. Active issues we are working on
a. Multiple copy/move ctors
VC doesn't correctly handle multiple copy/move ctors.
The workaround is under macro BOOST_HANA_WORKAROUND_MSVC_MULTIPLECTOR_106654.
b. Forward declaration of class template member function returning decltype(auto) (this issue is exposed by a recent change in boost 1.68)
To deduce the actual return type, the compiler expects the function definition to be on the pending list for temploid, which isn't always the case when generic lambda is involved.
The workaround is under macro BOOST_HANA_WORKAROUND_MSVC_DECLTYPEAUTO_RETURNTYPE_662735
2. Issues fixed in the development branch of MSVC
Parsing template id
VC sometimes incorrectly parses a comparison operation as a template id.
The workaround is under macro BOOST_HANA_WORKAROUND_MSVC_RDPARSER_TEMPLATEID_616568.
3. Issues fixed conditionally
a. Empty base optimization
VC doesn't always do EBO (empty base optimization). Changing this will break the ABI of MSVC and we provide a __declspec(empty_bases) to enable EBO.
We have a blog post on this: https://blogs.msdn.microsoft.com/vcblog/2016/03/30/optimizing-the-layout-of-empty-base-classes-in-vs2015-update-2-3/.
Some tests in hana have static_assert on the size of certain types which relies on EBO being applied:
hana\test\detail\ebo.cpp
hana\test\issues\github_202.cpp
hana\test\pair\empty_storage.cpp
hana\test\tuple\empty_member.cpp
The workaround is under macro BOOST_HANA_WORKAROUND_MSVC_EMPTYBASE.
b. Variadic macro expansion
The implementation of variadic macro isn't conformant and the macro expansion often results in incorrect result.
The issue is fixed under /experimental:preprocessor and isn't on by default yet.
We have a blog post on this: https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progress-towards-conformance/.
The workaround is under macro BOOST_HANA_WORKAROUND_MSVC_PREPROCESSOR_616033.
Here is the list of files impacted by the source workarounds:
BOOST_HANA_WORKAROUND_MSVC_MULTIPLECTOR_106654
hana\test\_include\laws\base.hpp
hana\test\map\cnstr.trap.cpp
hana\test\set\cnstr.trap.cpp
hana\test\tuple\cnstr.trap.cpp
BOOST_HANA_WORKAROUND_MSVC_DECLTYPEAUTO_RETURNTYPE_662735
hana\test\_include\laws\euclidean_ring.hpp
hana\test\_include\laws\group.hpp
hana\test\_include\laws\monad_plus.hpp
hana\test\_include\laws\monoid.hpp
hana\test\_include\laws\ring.hpp
BOOST_HANA_WORKAROUND_MSVC_RDPARSER_TEMPLATEID_616568
hana\include\boost\hana\basic_tuple.hpp
hana\include\boost\hana\string.hpp
hana\include\boost\hana\tuple.hpp
BOOST_HANA_WORKAROUND_MSVC_EMPTYBASE
hana\include\boost\hana\basic_tuple.hpp
hana\include\boost\hana\pair.hpp
hana\include\boost\hana\tuple.hpp
hana\include\boost\hana\detail\integral_constant.hpp
hana\test\detail\ebo.cpp
BOOST_HANA_WORKAROUND_MSVC_PREPROCESSOR_616033
hana\include\boost\hana\detail\preprocessor.hpp
hana\include\boost\hana\detail\struct_macros.hpp
BTW,
1. There are some warnings which I don't fix. I will likely address them in a separate PR. They look legit and don't impact the build and tests.
2. Appveyor currently doesn't provide 15.8 Preview 5 which contains all the compiler fixes we made in the previous months. I plan to update appveyor.yml after Appveyor provides 15.8 RTM.
- Use basic_tuple instead of closure<> for the inner storage
- Make sure the assignment operators are constexpr
- Copy the unit tests from closure<> (closure will eventually be removed anyway)
Fixes#165
