The wiki doesn't address adding test cases directly -- it only says no code changes -- hence the question. And now that I look at the actual pull request to master, my memory of the timing of my last sync is faulty. Sadly, not surprising. So there are 2 actual header changes (despite github claiming that there are many more merges needed in the pull I've reverified that master has everything except these 2 changes). One shuts down some warnings and the other fixes a bug in the constexpr implementation -- which I would like to close out in 1.74. Note that I have verified these on 5 versions of gcc in every mode from 98 to 2a -- and clang 10. And of course on develop for ~1 week with good tests. Let me know. https://github.com/boostorg/date_time/pull/164/commits/77495803c131764f44a5c... https://github.com/boostorg/date_time/pull/164/commits/247424d08de4587c70454... On Thu, Jul 16, 2020 at 6:26 AM Marshall Clow wrote:

On Jul 16, 2020, at 6:02 AM, Jeff Garland wrote:

I'd like to merge this one. It's docs, but there is a 'code change', to add some tests -- no core library changes. Asking since wasn't sure how that fit into the policy. Committed 3 days ago - test board looks good.

https://github.com/boostorg/date_time/pull/163/commits

Go ahead. — Marshall

P.S. I don’t think you have to ask to add tests.

Done -- thank you. On Thu, Jul 16, 2020 at 8:56 AM Marshall Clow wrote:

On Jul 16, 2020, at 8:47 AM, Jeff Garland wrote:

The wiki doesn't address adding test cases directly -- it only says no code changes -- hence the question.

And now that I look at the actual pull request to master, my memory of the timing of my last sync is faulty. Sadly, not surprising. So there are 2 actual header changes (despite github claiming that there are many more merges needed in the pull I've reverified that master has everything except these 2 changes). One shuts down some warnings and the other fixes a bug in the constexpr implementation -- which I would like to close out in 1.74. Note that I have verified these on 5 versions of gcc in every mode from 98 to 2a -- and clang 10. And of course on develop for ~1 week with good tests.

Let me know.

https://github.com/boostorg/date_time/pull/164/commits/77495803c131764f44a5c...

https://github.com/boostorg/date_time/pull/164/commits/247424d08de4587c70454...

Go ahead.

— Marshall

On Thu, Jul 16, 2020 at 6:26 AM Marshall Clow wrote:

...

On Jul 16, 2020, at 6:02 AM, Jeff Garland wrote:

I'd like to merge this one. It's docs, but there is a 'code change', to add some tests -- no core library changes. Asking since wasn't sure how that fit into the policy. Committed 3 days ago - test board looks good.

https://github.com/boostorg/date_time/pull/163/commits

Go ahead. — Marshall

P.S. I don’t think you have to ask to add tests.

On Jul 17, 2020, at 1:17 AM, Ion Gaztañaga via Boost wrote:

On 16/07/2020 7:36, Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy.

Hi,

I ask for permission to merge from develop (regression testing looks ok) two low-risk and a high priority issue (the regression was not fully completed before beta):

#128 (surprising move behavior) #126 (repeated include guard) #151 (buffer overflow)

Go ahead. — Marshall

On Jul 17, 2020, at 3:03 AM, Andrey Semashev via Boost wrote:

On 2020-07-16 08:36, Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy Reminder: The master branch closes for the release on August 5th.

I would like to merge the following commit to master:

https://github.com/boostorg/core/commit/503d035b7fa3e4d10da4d81eb4e6df0f0804...

It is a workaround for compilation error of boost::uncaught_exceptions on AIX with xlclang++ compiler. The CI tests have passed.

Approved. — Marshall

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..., 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

On 21/07/2020 15:51, Alexander Grund via Boost wrote:

...

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...,

I'd appreciate the help.

Just some observations that might help:

- Failing test is BOOST_CHECK(a == b); with "outcome<int> a(1);    result<int> b(1);" - Hence the operation is "operator==(outcome, result) - Failing stacktrace shows bottom-most: "operator==(const basic_result &a, const basic_outcome &b)" so the other way round - you define the availability and noexceptness basically as "b == a" reversing the results

All correct.

Is it possible that outcome<T> and result<T> are convertible? If so, that would explain the recursion: to check a==b you need to check b==a so you need to check a==b, ...

An outcome<T> can be explicitly constructed from a result<T> yes. But the recursion isn't from that. result == outcome is available if outcome == result is available. outcome == result is available if the expressions A == C and B == D are valid. As A and C are both ints, and B and D are both error_code, this should "just work", and indeed it does on GCC and MSVC, and indeed clang if in a C++ standard before C++ 20. For some reason I don't understand, clang in C++ 20 mode seems to loop the result == outcome step i.e. in the constraints that result == outcome is available if and only if outcome == result is available, it considers the availability of the result == outcome overload itself. As you suggest, if an outcome were *implicitly* constructible from a result, that might be a valid consideration. But it is not available due to the explicit constructibility, so the compiler should never consider it. Another option is that this is simply a corner case bug in clang. Xcode's clang is actually pretty bug ridden, Outcome's unit tests fail badly on Xcode clang, I had to go disable a whole bunch of them to achieve a pass. But LLVM clang is pretty good, generally. It's the best of all the major compilers for this sort of stuff, in my opinion. Now, there is the argument that in C++, just because A == B is available doesn't mean than B == A is available, and Outcome ought to reflect that properly. This is one of those many areas where I've deliberately been lazy, and not spent code and thus maintenance time on what are in my opinion pathological corner case support. To date, no users have complained :) Niall

Niall Douglas wrote:

For some reason I don't understand, clang in C++ 20 mode seems to loop the result == outcome step i.e. in the constraints that result == outcome is available if and only if outcome == result is available, it considers the availability of the result == outcome overload itself.

Probably caused by C++20 operator rewriting that was introduced as part of the op<=> changes. The gift that keeps giving.

On 22/07/2020 15:59, Alexander Grund via Boost wrote:

Am 22.07.20 um 16:56 schrieb Peter Dimov via Boost:

...

Niall Douglas wrote:

...

For some reason I don't understand, clang in C++ 20 mode seems to loop the result == outcome step i.e. in the constraints that result == outcome is available if and only if outcome == result is available, it considers the availability of the result == outcome overload itself.

Probably caused by C++20 operator rewriting that was introduced as part of the op<=> changes. The gift that keeps giving.

BOOM, yes! Good idea, I guess that's it.

You've suddenly reminded me why I had added the below check:

Maybe the "#if __cplusplus <= 202000L" I mentioned earlier was meant to say "#if __cplusplus < 202000L" due to this?

The check is good, as the official value is 202002L. But it is misleading. I will fix it. That test failure in Outcome has been around for so long now that I had originally thought of C++ 20 operator rewriting, added that check, then forgot that, and now we are here. The reason why clang still fails is because it sets __cplusplus to 2017, even if it's been told it is in C++ 20, which is extremely unhelpful of it. So Peter, seeing as you're the closest person to an expert in C++ 20 operator rewriting that I know of (and there is absolutely nothing about this on the internet), can you tell me if C++ 20 automagically rewrites an available operator==(A, B) into an operator==(B, A) with no further suggestion? i.e. if I simply #ifdef out that code if on C++ 20 or later, am I good? Niall

On 22/07/2020 17:39, Andrey Semashev via Boost wrote:

On 2020-07-22 19:25, Niall Douglas via Boost wrote:

...

So Peter, seeing as you're the closest person to an expert in C++ 20 operator rewriting that I know of (and there is absolutely nothing about this on the internet),

FWIW, I found this article helpful to understand the new operators behavior:

https://brevzin.github.io/c++/2019/07/28/comparisons-cpp20/

TL;DR version is in the summary:

https://brevzin.github.io/c++/2019/07/28/comparisons-cpp20/#summary-of-rules

That was very useful. It turns out that for operator== only, C++ 20 will auto reverse it. So, in Outcome, I need to disable free function reversed operator== only, for C++ 20 and later. I must leave free function reversed operator!= alone. Now all we need is for clang to stop claiming C++ 17 when it's in C++ 20. I understand clang 11 will be the first to do this. Until then, Boost.Outcome can never be 100% green in the Boost test suite. (Apart from MSVC that is. They have a long standing instability bug in two phase lookup where depending on random chance, either MSVC discovers ADL injected hooks, or it doesn't, per compilation. They know about the bug, and there is no estimate for when it will be fixed. This is why in the Boost regression suite, the hooks test randomly flips from passed to fail all the time for MSVC) Thanks everybody for your help. Niall

On 2020-07-22 21:15, Andrey Semashev wrote:

On 2020-07-21 12:18, Andrey Semashev wrote:

...

On 2020-07-16 08:36, Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy.

See https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy

Reminder: The master branch closes for the release on August 5th.

I'd like to merge to master the following commit:

https://github.com/boostorg/core/commit/dcc04c55089b8a74c5a37e3d25694fca697f...

It is a workaround for boost::uncaught_exceptions on older versions of Mac OS and iOS. CI tests have passed.

Ping?

Ping again? Can I merge this?

I'd like to merge a small fix for building on Android with API level below 24: https://github.com/boostorg/nowide/pull/112/files CI passed, expecting the reporter to confirm it is working for him today. Thanks, Alex

On Wed, Jul 22, 2020 at 5:37 AM Alexander Grund via Boost wrote:

I'd like to merge a small fix for building on Android with API level below 24: https://github.com/boostorg/nowide/pull/112/files

May I merge this? CI has passed and it reportedly fixes the issue.

Yes. Glen

On Fri, 24 Jul 2020 at 15:57, Marshall Clow via Boost wrote:

...

On Jul 24, 2020, at 3:17 AM, Richard Hodges via Boost < boost@lists.boost.org> wrote:

I'd like to commit the following from beast/developto beast/master:

Version bump:

https://github.com/boostorg/beast/commit/201105e66ab738bd8e027cff8c11ddd7cd5...

...

Fix portability bug in example with old compiler

https://github.com/boostorg/beast/commit/2efb729c53124266f5807cb6e56fe145dfc...

...

Fix portability bug in example with old compiler

https://github.com/boostorg/beast/commit/4f913cab6377ddda0b5e085a9d481937ea8...

...

Dockerfiles for improved testing

https://github.com/boostorg/beast/commit/b168f6242dc976800a2cb9f722644cd8091...

...

https://github.com/boostorg/beast/commit/28a7a99e759ee3e783bd8908a2d4fdbe656...

...

Please advise when convenient.

Go ahead.

merged

— Marshall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

On Fri, Jul 24, 2020 at 7:25 AM Antony Polukhin via Boost wrote:

I'd like to merge the following fixes:

1) Missing include in LexicalCast https://github.com/boostorg/lexical_cast/commit/9fdbf5ce67d9a9302cf16de4760d... 2) Missing includes in DLL https://github.com/boostorg/dll/commit/6fed722419caec8ff1049ea0e78afcd75daa6... 3) Variant issue that was preventing it from being used with Thread https://github.com/boostorg/variant/commit/03035b2f6b5d48d82270725f6eb529681... (thanks to Andrzej Krzemieński for the diagnose and fix!)

You're good to merge. Glen

On Jul 28, 2020, at 7:35 AM, Andrey Semashev via Boost wrote:

On 2020-07-16 08:36, Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy Reminder: The master branch closes for the release on August 5th.

I'd like to merge the following commits to master:

https://github.com/boostorg/filesystem/commit/db390391bb144544c2a30ff225c4c3... https://github.com/boostorg/filesystem/commit/96ff4a1fe6c667bf9fc38ad191d66e...

The commits restore (but deprecate) auto-linking with Windows SDK libraries used internally by Boost.Filesystem. This is a workaround for possible linking errors if users use static library of Boost.Filesystem and don't link these libraries in their projects.

CI tests have passed.

Go ahead. — Marshall

On Jul 29, 2020, at 3:44 AM, Andrey Semashev via Boost wrote:

On 2020-07-16 08:36, Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy Reminder: The master branch closes for the release on August 5th.

I'd like to merge the following commit to master:

https://github.com/boostorg/filesystem/commit/4748f6e39da4948468391705fdd140...

It adds O_CLOEXEC to the open call used in /dev/random-based unique_path implementation.

CI tests have passed.

Go ahead. — Marshall

On Jul 29, 2020, at 9:31 AM, Vinnie Falco via Boost wrote:

On Wed, Jul 15, 2020 at 10:38 PM Marshall Clow via Boost wrote:

...

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy.

There's a warning coming from Boost.Coroutine, from including which is now a deprecated header. Can we please fix this for the release? Every Beast and Asio user who tries to use Asio's stackful coroutines will get this warning.

The best way to get this fixed is be to make a pull request against Boost.Coroutine. The second-best way would be to open a Github issue against Boost.Coroutine. The third-best way would be to email Oliver Kowalke, the owner of Boost.Coroutine. (pro-tip: the file libs/maintainers.txt is a handy reference) The fourth-best way is to ask about it on this mailing list. :-) — Marshall