On 27/01/2018 22:06, Glen Fernandes wrote:
On Sat, Jan 27, 2018 at 4:55 PM, Glen Fernandes wrote:
I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux with libstdc++ with -std=c++14 and -std=c++1z which fails with many errors:
e.g. [snip] In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: error: no template named 'conditional_t' in namespace 'std'; did you mean 'conditional'? template <class T> using devoid = std::conditional_t<std::is_void<T>::value, void_type, T>; ~~~~~^~~~~~~~~~~~~ conditional /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: note: 'conditional' declared here struct conditional
That's an ancient version of libstdc++ 4.8 which does not provide sufficient C++ 14 support. As the documentation says at https://ned14.github.io/outcome/requirements/, you need GCC 6.3 or later. Thus libstdc++ would also need to be 6.3 or newer.
Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 with libc++ with -std=c++14 and -std=c++1z which fails with errors like:
Again, as https://ned14.github.io/outcome/requirements/ says, XCode 9 or newer is required. The implementation of C++ 14 in XCode 8 is insufficient.
Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on Linux seem to pass. The other combinations I tried (clang + lisbtdc++ on Linux, Apple clang + libc++) do not.
I spoke too soon, here gcc 7 does not pass. It ICEs: [snip] Let me know if you need more context, but it appears boost-outcome is also broken on gcc 7.2.
There's a long standing memory corruption bug in GCC's constexpr implementation which Outcome's unit tests may trigger sometimes. The GCC maintainers know well of this bug, and efforts continue to track it down and fix it. The problem is that it is not repeatable across machines. I may get consistently an ICE here on my machine (I do!), but Travis running the exact same compiler and test suite does not (also true!). Same problem when say Jason Merrill runs a repro I send him, and it works perfectly on his machine, yet ICEs on mine. If you're using Outcome heavily in 100% constexpr programming, then you are advised to use clang or - and I kid you not here - MSVC until GCC gets its constexpr implementation fixed. Again, none of this is Outcome's fault. These are bugs in compilers. I would also add that in day to day programming, GCC's constexpr problems don't really manifest. They appear only when heavily stressed in say a test suite which runs lots of corner case scenarios that would never happen in real life. Equally, if when programming with Outcome and you see GCC ICEing in constexpr, either remove the constexpr or use a different compiler. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/