Those are old compilers and removing support allows removing a couple
of workarounds. It also reduces the CI burden and will allow us to test
more recent and more relevant compilers.
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 is done by generating the supporting preprocessor macros with ERB up to
the required arity, like we do for the struct macros themselves.
Fixes#376
- Adds index_if
- Rewrites detail::index_if to use recursive alias stuff
optimized for tuple and basic_tuple
- find_if now uses index_if for Iterables
- at_key now uses index_if for Sequence
- Removes duplicate code and unnecessary special case implementations
- detail::advance_until
- at_key::advance_until
- tuple_tag implementation of find_if
- Uses Foldable instead of Sequence for cases where length is known.
(find_if had a specialization when Iterable and not Sequence)
- Adds test.*.auto.index_if for Sequences
- Adds test support/counter for testing infinite iterables
MSVC doesn't like the #warning directive and issues a fatal error.
It also sets _MSVC_LANG to 201402 for C++14 instead of __cplusplus,
but that's the minimum value anyway.
It also doesn't like using {} instead of ::value for some type traits
sometimes and issues an error about a missing default constructor.
[ldionne: add full break after first line in commit message]
Note that no `norm` function is added for now, since the `norm` is not
tied to the specific Euclidean ring as explained in [1]. However, it
might be useful to enforce an arbitrary choice to be made for each
Euclidean ring. This could perhaps be added in the future.
Fixes#28
[1]: https://en.wikipedia.org/wiki/Euclidean_domain#Definition
Also, make existing Constants models of IntegralConstant. This fixes#132
by making the definition of a model of Constant reasonably easy for
IntegralConstants.
The `models<>` machinery added unnecessary complexity for little benefit.
Also, this makes Hana's concepts syntactically closer to concepts lite,
which should contribute to making them easier to grasp at first sight.
This was annoying because
(1) We couldn't use the name hana:: from within the struct
(2) It requires one more instantiation unless you use the
`using hana = self` trick. But that trick makes something
that should be trivial to do slightly harder, and that is stupid.
This (large) commit introduces the following changes:
- Each algorithm lives in its own header
- The concepts are defined in the concept/ subdirectory. They define the
`models` metafunction, some explicit default implementations (like
Applicative::transform_impl), and they include all the algorithms
related to that concept.
- Removed the `until` method from Logical
- Removed the `drop_until` method from Iterable
- [minor] Added the detail::nested_to utility
Closes#160
There was a legitimate reason to have this duplication when the library
was much smaller. However, hovering at about 30 kLOCs, the library is
definitely not small enough anymore to mandate reimplementing our own
<type_traits>. Also, most user code will probably include <type_traits>
anyway, so using <type_traits> will not increase the overall compilation
time in actual code bases.
Finally, this gives us much more flexibility, like the ability to
inherit our IntegralConstant from std::integral_constant, and then
return that from the traits:: metafunctions, so that operators can
be used with them.
This is done because the resulting macros are much more straightforward
to debug when a user makes a mistake. Also, it avoids pulling yet another
dependency.
Also added some general purpose macros in detail/preprocessor.hpp.
