As we bump the compiler requirements, it becomes unreasonable to issue
a warning for compilers that might work with Hana, but that are not
officially supported.
In most cases, this shouldn't be necessary if we detect the compiler
being used. Strictly speaking, this isn't true because someone could
override the Standard Library with any compiler. However, the logic
for detecting the Standard Library is broken for recent libc++'s, and
I don't want to maintain that.
Also, the Standard Libraries that are not supported are getting more
and more ancient, so the benefit of having these warnings in place is
getting smaller and smaller.
Explicit instantiations of const variables templates are not given
internal linkage by default, so defining curry_or_call<0> was an
ODR violation (a global defined in all TUs where it's included).
In LLVM parlance, we could either give it linkonce_odr semantics
(with C++17 inline variables) or give it internal linkage. Since
Hana is a C++14 library and I don't think there will be any code
bloat associated to this, I'm going with internal linkage.
Fixes#446
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.
Also, add tests to make sure that an empty pair can be EBO'd. This one is very
important because a typical use case is to create a tuple of pairs of empty
types (e.g. in hana::map), and we expect this to be empty.
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
This used to guard against a bug in the std::tuple implementation, but it
seems like this bug was fixed in subsequent minor releases of Clang 3.5 and
3.6, which we test against.
When C++17 is supported, constexpr lambdas can be used and CONSTEXPR_ASSERT
turns into an actual static_assert. This is not unconditionally enabled for
now because Clang does not support constexpr lambdas with captures (!).
We were using `&arr[0]` on empty arrays, which is technically UB since `arr[0]`
is UB on empty arrays. This triggered an infinite loop on Clang-on-Windows.
