Morwenn / tight_pair

A compressed pair for C++17
MIT License
25 stars 2 forks source link

Two errors about incomplete type when using gcc and libstdcxx #1

Closed FirstLoveLife closed 5 years ago

FirstLoveLife commented 5 years ago

libcxx/const_pair_U_V.cpp and libcxx/rv_pair_U_V.cpp cannot pass compilation:

[ 28%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/piecewise_no_copy_move.cpp.o
[ 31%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/reference_wrapper.cpp.o
[ 33%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/tricky_comparisons.cpp.o
[ 35%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/assign_const_pair_U_V.cpp.o
[ 37%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/assign_pair.cpp.o
[ 40%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/assign_rv_pair.cpp.o
[ 42%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/assign_rv_pair_U_V.cpp.o
[ 44%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/assign_tuple.cpp.o
[ 46%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/comparison.cpp.o
[ 48%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/const_first_const_second.cpp.o
[ 51%] Building CXX object tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/const_pair_U_V.cpp.o
In file included from /usr/include/c++/8.2.1/bits/unique_ptr.h:37,
                 from /usr/include/c++/8.2.1/memory:80,
                 from /usr/include/catch.hpp:445,
                 from /home/firstlove/fork/tight_pair/tests/libcxx/const_pair_U_V.cpp:25:
/usr/include/c++/8.2.1/tuple: In instantiation of ‘constexpr const size_t std::tuple_size_v<{anonymous}::DPair<long int, long int> >’:
/home/firstlove/fork/tight_pair/tight_pair.h:262:26:   required from ‘struct cruft::detail::adl_hook::pair_like_impl<{anonymous}::DPair<long int, long int>, void>’
/home/firstlove/fork/tight_pair/tight_pair.h:265:30:   required from ‘struct cruft::detail::pair_like<{anonymous}::DPair<long int, long int> >’
/home/firstlove/fork/tight_pair/tight_pair.h:723:79:   required by substitution of ‘template<class Tuple, typename std::enable_if<typename std::conditional<(cruft::detail::pair_like<typename std::remove_reference<_Tp>::type>::value && (! is_same_v<typename std::decay<_Tp>::type, cruft::tight_pair<int, int> >)), cruft::tight_pair<int, int>::check_tuple_like_constructor, cruft::detail::check_tuple_constructor_fail>::type::enable_explicit<Tuple>(), void>::type <anonymous> > constexpr cruft::tight_pair<int, int>::tight_pair(Tuple&&) [with Tuple = {anonymous}::DPair<long int, long int>&; typename std::enable_if<typename std::conditional<(cruft::detail::pair_like<typename std::remove_reference<_Tp>::type>::value && (! is_same_v<typename std::decay<_Tp>::type, cruft::tight_pair<int, int> >)), cruft::tight_pair<int, int>::check_tuple_like_constructor, cruft::detail::check_tuple_constructor_fail>::type::enable_explicit<Tuple>(), void>::type <anonymous> = <missing>]’
/home/firstlove/fork/tight_pair/tests/libcxx/const_pair_U_V.cpp:91:17:   required from here
/usr/include/c++/8.2.1/tuple:1271:29: error: incomplete type ‘std::tuple_size<{anonymous}::DPair<long int, long int> >’ used in nested name specifier
     inline constexpr size_t tuple_size_v = tuple_size<_Tp>::value;
                             ^~~~~~~~~~~~
make[2]: *** [tests/CMakeFiles/tight-pair-testsuite.dir/build.make:245: tests/CMakeFiles/tight-pair-testsuite.dir/libcxx/const_pair_U_V.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:146: tests/CMakeFiles/tight-pair-testsuite.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

clang has no errors and can pass complaination with libcxx:

set(CMAKE_CXX_COMPILER "clang++")
set(CMAKE_C_COMPILER "clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -lc++abi")
Morwenn commented 5 years ago

I'm quite surprised considering I mainly use GCC and libstdc++ when developing. I will look at that issue when I find some time.

Morwenn commented 5 years ago

I managed to reproduce the bug with the latest GCC, which means that SFINAE or template instantiation is not handled exactly the same way for some reason compared to previous versions. Your fix wasn't enough but I did include it too because it was a nice pedantic addition :)