Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2

Subject: Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-28 00:05:48

>> https://travis-ci.org/ned14/boost-outcome
>>
>> https://travis-ci.org/ned14/outcome
>>
>> https://ci.appveyor.com/project/ned14/outcome
>>
> 
> The first one is for boost-outcome, correct? It only tests g++-6 with
> c++14, not g++-7 (in 14 or 17) (where the ICE occurs), or or
> clang+libc++ (where your other errors were).

The same constexpr ICE problem afflicts GCC 6. But similarly it happens
randomly across machines.

> Aren't the second and third for standalone outcome? That isn't being
> reviewed here, correct? (i.e. Standalone outcome doens't even ICE
> MSVC2017 with Vinnie's test case, but boost-outcome, the one being
> submitted for review, does?).

I didn't think it necessary to run more CIs than at present. I know they
appear to be free to us, but I felt it anti-social to be using more jobs
than is strictly necessary. And the existing CIs cover all of MSVC,
clang and GCC, with Dinkumware, libstdc++ and libc++ on Linux, Windows
and MacOS. That's a good cross section of the most common configurations.

I am surprised about the clang + libc++ missing header because the XCode
9 CI job ought to have caught that, but that happens sometimes.

boost-outcome is the same library as Outcome standalone, if you do a
side by side diff you'll see that. The only change is the use of
Boost.Config instead of SD6 feature macros, and Boost.Exception. Hence I
felt that boost-outcome didn't need much testing above making sure it
works inside Boost, which is what the CI job does.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/