Bug 245574 – error: static assertion failed due to requirement 'is_same<JSC::UnlinkedCallLinkInfo &, const JSC::UnlinkedCallLinkInfo &>::value'

• Component: JavaScriptCore
• Status: RESOLVED DUPLICATE

[Manuel Nickschas]

Created attachment 462561 [details]
Build log

When trying to build webkit-gtk against the newly released libcxx-15.0.1, I get the following static assertion:

In file included from /var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8_build/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-3a3c4ec0-3.cpp:1:
In file included from /var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8/Source/JavaScriptCore/jit/JIT.cpp:26:
In file included from /var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8/Source/JavaScriptCore/config.h:38:
In file included from /var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8_build/WTF/Headers/wtf/FastMalloc.h:26:
In file included from /var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8_build/WTF/Headers/wtf/StdLibExtras.h:30:
In file included from /usr/include/c++/v1/memory:842:
In file included from /usr/include/c++/v1/__algorithm/move.h:12:
/usr/include/c++/v1/__algorithm/iterator_operations.h:100:5: error: static assertion failed due to requirement 'is_same<JSC::UnlinkedCallLinkInfo &, const JSC::UnlinkedCallLinkInfo &>::value': It looks like your iterator's `iterator_traits<It>::
reference` does not match the return type of dereferencing the iterator, i.e., calling `*it`. This is undefined behavior according to [input.iterators] and can lead to dangling reference issues at runtime, so we are flagging this.
    static_assert(is_same<__deref_t<_Iter>, typename iterator_traits<__uncvref_t<_Iter> >::reference>::value,
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__algorithm/iterator_operations.h:115:5: note: in instantiation of function template specialization 'std::_IterOps<std::_ClassicAlgPolicy>::__validate_iter_reference<WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8> &>' requested here
    __validate_iter_reference<_Iter>();
    ^
/usr/include/c++/v1/__algorithm/move.h:34:39: note: in instantiation of function template specialization 'std::_IterOps<std::_ClassicAlgPolicy>::__iter_move<WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8> &>' requested here
    *__result = _IterOps<_AlgPolicy>::__iter_move(__first);
                                      ^
/usr/include/c++/v1/__algorithm/move.h:97:21: note: in instantiation of function template specialization 'std::__move_impl<std::_ClassicAlgPolicy, WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8>, WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8>, JSC::UnlinkedCallLinkInfo *>' requested here
  auto __ret = std::__move_impl<_AlgPolicy>(
                    ^
/usr/include/c++/v1/__algorithm/move.h:114:15: note: in instantiation of function template specialization 'std::__move<std::_ClassicAlgPolicy, WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8>, WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8>, JSC::UnlinkedCallLinkInfo *>' requested here
  return std::__move<_ClassicAlgPolicy>(__first, __last, __result).second;
              ^
/var/tmp/portage/net-libs/webkit-gtk-2.36.8/work/webkitgtk-2.36.8/Source/JavaScriptCore/jit/JIT.cpp:993:14: note: in instantiation of function template specialization 'std::__1::move<WTF::SegmentedVectorIterator<JSC::UnlinkedCallLinkInfo, 8>, JSC::UnlinkedCallLinkInfo *>' requested here
        std::move(m_unlinkedCalls.begin(), m_unlinkedCalls.end(), m_jitCode->m_unlinkedCalls.begin());
             ^

This used to work with previous versions of libcxx, so I guess something was made stricter inside the library.

[Michael Catanzaro]

I think this is actually a libc++ bug. It occurs when #including the <memory> header. You have one libc++ header triggering an error in another libc++ header, so I'd say you've just got a broken version of libc++? You could probably reproduce without WebKit with any program that just #includes <memory>.

[Michael Catanzaro]

Wait sorry, I see JSC symbols in the error message. I guess I'm real bad at reading today.

[Manuel Nickschas]

Just wanted to say, I have built my whole system against that libc++, I probably would've noticed a broken <memory> ;-)

[Radar WebKit Bug Importer]

<rdar://problem/100609108>

[Yusuke Suzuki]

Thanks, this is dupe of bug 245183

*** This bug has been marked as a duplicate of bug 245183 ***