Re: [release] 1.74.0 post-beta merges

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-07-21 13:50:57

On 20/07/2020 18:50, Marshall Clow wrote:

>> I'd like permission to merge a fix for
>> https://github.com/ned14/outcome/issues/232 (Cannot use expressions
>> involving variables named `res` within `OUTCOME_TRYX` and friends). The
>> change delta would be that anywhere around
>> https://github.com/ned14/outcome/blob/develop/include/outcome/try.hpp#L223
>> where it currently has "res", it would thereafter become
>> OUTCOME_TRY_UNIQUE_NAME. Nothing apart from the bug fix (including ABI
>> and API) would change.
> 
> If the answers are “yes”, and “fine”, then go ahead.

That fix is merged.

I'd like to merge another fixing all the test breakages shown at
https://www.boost.org/development/tests/develop/developer/outcome.html.
This was caused by Emil reverting the boost::make_exception_ptr()
addition. I've simply bumped the Boost version guard, as I'd assume
he'll unrevert it after the release.

Finally, if anyone more expert at C++ than I can suggest how to fix
https://www.boost.org/development/tests/develop/developer/output/teeks99-dkr-dc10-2a-lc-boost-bin-v2-libs-outcome-test-comparison-test-clang-linux-10~c++2a~lc-debug-threading-multi-visibility-hidden.html,
I'd appreciate the help.

I have tried six different approaches to solving that failure which
occurs only on clang, and only if clang is in C++ 20 mode. Neither GCC
nor MSVC take issue with it, in any C++ version. I have exceeded my
understanding of C++. I don't know what to do to fix it.

(Before anyone suggests "use SFINAE instead of Concepts", yes I tried
that, same failure. Before anyone suggests further constraints to break
the template recursion, yes I tried that too, but there is an
inescapable chicken and egg problem, I have to define the bloody type
before I can set constraints about it. To me, SFINAE means "substitution
failure is not an error", so if clang fails to substitute due to
recursion, I'd call that not an error. The really weird thing is that
clang before C++ 20 is happy, so knowing that the clang authors are not
incompetent, some rule must have changed in C+ 20. It's beyond me)

Niall