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.
This allows us to create large maps quite efficiently. If one needs
to create a map with duplicate keys or keys whose hashes may collide,
the inefficient to_map can be used instead.
- Rename test/_support to test/_include
- Move stuff from test/_include/test to test/_include/support
- Move stuff in test/_include/support into global namespace
This essentially undo parts of 307d3d0. While it seemed a like good
idea to over-modularize type classes to reduce header dependencies, I
think it was a mistake. What 307d3d0 did was basically split each of
the components of a type class into a single header (typeclass/operators.hpp,
typeclass/mcd_1.hpp, typeclass/mcd_2.hpp, ...).
At first, it resolved many weird header dependency glitches. However, it
also made everything more complex; creating even easy type classes was
sometimes much longer than it should have been, and using type classes
was tricky because you had to know exactly what to include. It also went
against the idea of implicit type class instances being provided whenever
that's possible, which I think is a nice feature of the library. Being
dissatisfied with this, I opted for a simpler header organization with
a fwd/ directory that contains forward declaration headers, and everything
else in the same directory.
A possible objection to this change would be that you are now forced
to include sometimes more than what you strictly need when e.g. defining
an instance or using only some instance(s) of a data type. My answer to
this is that Hana is a really small library and the parsing is not
going to have a huge impact on overall compilation time. My bet is that
the time that will be saved by programmers with a simple header hierarchy
outweights the parsing time by far.
- Split type class instances into separate files
- Instances provided automatically by a type class are actually MCDs
- Test each instance in a single file, not one file per method
- Refactor the operator system to fix the ADL-related bug.
