[release] 1.74.0 post-beta merges
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. -- The release managers
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 On Wed, Jul 15, 2020 at 10:37 PM Marshall Clow via Boost < boost@lists.boost.org> 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.
-- The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jul 16, 2020, at 6:02 AM, Jeff Garland <azswdude@gmail.com> 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 <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.
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 <mclow.lists@gmail.com> wrote:
On Jul 16, 2020, at 6:02 AM, Jeff Garland <azswdude@gmail.com> 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 16, 2020, at 8:47 AM, Jeff Garland <azswdude@gmail.com> 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/77495803c131764f44a5c4d2227883d8c6812ead> https://github.com/boostorg/date_time/pull/164/commits/247424d08de4587c70454... <https://github.com/boostorg/date_time/pull/164/commits/247424d08de4587c7045467e172414b4ce9d4b20>
Go ahead. — Marshall
On Thu, Jul 16, 2020 at 6:26 AM Marshall Clow <mclow.lists@gmail.com <mailto:mclow.lists@gmail.com>> wrote: On Jul 16, 2020, at 6:02 AM, Jeff Garland <azswdude@gmail.com <mailto:azswdude@gmail.com>> 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 <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 <mclow.lists@gmail.com> wrote:
On Jul 16, 2020, at 8:47 AM, Jeff Garland <azswdude@gmail.com> 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 <mclow.lists@gmail.com> wrote:
On Jul 16, 2020, at 6:02 AM, Jeff Garland <azswdude@gmail.com> 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 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) Best, Ion
On Jul 17, 2020, at 1:17 AM, Ion Gaztañaga via Boost <boost@lists.boost.org> 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 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.
On Jul 17, 2020, at 3:03 AM, Andrey Semashev via Boost <boost@lists.boost.org> 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 Wed, Jul 15, 2020 at 10:38 PM Marshall Clow via Boost <boost@lists.boost.org> wrote:
...
Heads up, someone found a compile error that we are in the process of resolving: <https://github.com/boostorg/beast/issues/2021> Happens on gcc-4.8.5-4.el7.x86_64 under CentOS 7 Thanks
On 16/07/2020 06: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 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. Niall
On Jul 20, 2020, at 10:06 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
On 16/07/2020 06: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 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.
Have you landed this on ‘develop’? How do the tests look there? If the answers are “yes”, and “fine”, then go ahead. — 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
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<T, U, V> &a, const basic_outcome<R, S, P, N> &b)" so the other way round - you define the availability and noexceptness basically as "b == a" reversing the results 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, ... If that is the case I don't think it is possible to overcome this. However if those are convertible, why is the swapping required? Also: Is the guard around that function "#if __cplusplus <= 202000L" correct? If so why would you exclude C++23 and up now? My feeling is that the operator is not required and can be removed which avoids the recursion. Hope that asks the right question to point you into solving this. Regards, Alex
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<T, U, V> &a, const basic_outcome<R, S, P, N> &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<A, B> == result<C, D> 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
Am 22.07.20 um 16:38 schrieb Niall Douglas via Boost:
On 21/07/2020 15:51, Alexander Grund via Boost wrote:
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<T, U, V> &a, const basic_outcome<R, S, P, N> &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<A, B> == result<C, D> 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 :)
What about the fact that Clang considers "operator==(const basic_result, const basic_outcome)" for a test "operator==(outcome, result)"? Have you checked that? This way you might find where it converts one into another. Maybe even check that in isolation by assigning "b = a" first and see what it does. Could you check that locally in a file having only this? Maybe remove the constraints for this test to make it compile and debug it through to see why it tries that? For why "clang in C++20": You switch your macros to use concepts instead of template sfinae in C++20, don't you? If so, temporarily disable that? Maybe this switch enables a ctor that is otherwise explicit or disabled?
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.
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. Maybe the "#if __cplusplus <= 202000L" I mentioned earlier was meant to say "#if __cplusplus < 202000L" due to this?
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 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
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 Wed, 22 Jul 2020, Niall Douglas via Boost wrote:
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.
Because operator== rewriting broke quite a bit of code, some committee people are trying to revert this change (make it opt-in or something) via DR. So it may be safer for now to write code in a way that works for both C++17 and C++20 rules without #ifdefs, where possible (or fully use <=> where that makes sense, which counts as opt-in). -- Marc Glisse
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.
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?
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?
On Jul 25, 2020, at 4:54 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
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?
Go ahead. — Marshall
I'd like to merge https://github.com/boostorg/variant/pull/81/files into master. Tests are fine. On Thu, Jul 16, 2020, 08:37 Marshall Clow via Boost <boost@lists.boost.org> 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.
-- The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Jul 21, 2020 at 11:18 AM Antony Polukhin via Boost <boost@lists.boost.org> wrote:
I'd like to merge https://github.com/boostorg/variant/pull/81/files into master. Tests are fine.
Go ahead. Glen
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
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. Thanks, Alex
On Wed, Jul 22, 2020 at 5:37 AM Alexander Grund via Boost <boost@lists.boost.org> 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 Jul 22, 2020, at 2:37 AM, Alexander Grund via Boost <boost@lists.boost.org> 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.
Go ahead. — Marshall
Requesting permission to merge last minute bug fixes that will improve user experience (and allow compilation with some compilers) https://github.com/boostorg/beast/pull/2026 On Thu, 16 Jul 2020 at 07:37, Marshall Clow via Boost <boost@lists.boost.org> 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.
-- The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
On Wed, Jul 22, 2020 at 12:17 PM Richard Hodges via Boost <boost@lists.boost.org> wrote:
Requesting permission to merge last minute bug fixes that will improve user experience (and allow compilation with some compilers)
There are two commits here which I think are far too risky to slip in at the last minute: <https://github.com/boostorg/beast/pull/2026/commits/ee782d40225c8cc1d275ac74b183ff01fba13785> <https://github.com/boostorg/beast/pull/2026/commits/fcabb8f2d8771c60398806fc44f95c1a4ffd4df2> The post-beta merge period is not the time for these sorts of changes. The other commits are fine. Thanks
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. R On Thu, 16 Jul 2020 at 07:37, Marshall Clow via Boost <boost@lists.boost.org> 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.
-- The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
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. — Marshall
On Fri, 24 Jul 2020 at 15:57, Marshall Clow via Boost <boost@lists.boost.org> 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
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!) -- Best regards, Antony Polukhin
On Fri, Jul 24, 2020 at 7:25 AM Antony Polukhin via Boost <boost@lists.boost.org> 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 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.
On Jul 28, 2020, at 7:35 AM, Andrey Semashev via Boost <boost@lists.boost.org> 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 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.
On Jul 29, 2020, at 3:44 AM, Andrey Semashev via Boost <boost@lists.boost.org> 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 Wed, Jul 15, 2020 at 10:38 PM Marshall Clow via Boost <boost@lists.boost.org> 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 <boost/detail/scoped_enum_emulation.hpp> 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. Thanks
On Jul 29, 2020, at 9:31 AM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Wed, Jul 15, 2020 at 10:38 PM Marshall Clow via Boost <boost@lists.boost.org> 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 <boost/detail/scoped_enum_emulation.hpp> 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
On 2020-07-30 02:03, Marshall Clow via Boost wrote:
On Jul 29, 2020, at 9:31 AM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Wed, Jul 15, 2020 at 10:38 PM Marshall Clow via Boost <boost@lists.boost.org> 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 <boost/detail/scoped_enum_emulation.hpp> 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.
...or maybe port code away from the deprecated header.
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'd like to merge fix for another missing include https://github.com/boostorg/variant/commit/5e989572aea2c2d39c1268acb29558431... On Thu, Jul 16, 2020, 08:37 Marshall Clow via Boost <boost@lists.boost.org> 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.
-- The release managers
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Friday, July 31, 2020, Antony Polukhin via Boost <boost@lists.boost.org> wrote:
I'd like to merge fix for another missing include https://github.com/boostorg/variant/commit/5e989572aea2c2d39c1268acb29558 431deb8902
Go for it. Glen
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/log/commit/e7d4fd2d13f753cee86ac2ffd82259ab460e1... This is a fix for Boost.Log compilation on platforms that don't support native syslog or Boost.ASIO. CI tests have passed.
On Aug 1, 2020, at 5:36 PM, Andrey Semashev via Boost <boost@lists.boost.org> 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/log/commit/e7d4fd2d13f753cee86ac2ffd82259ab460e1...
This is a fix for Boost.Log compilation on platforms that don't support native syslog or Boost.ASIO. CI tests have passed.
That looks fine to me. — Marshall
W dniu 16.07.2020 o 07:36, Marshall Clow via Boost pisze:
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 some bugfixes: https://github.com/boostorg/geometry/compare/master...develop
Adam
On Aug 3, 2020, at 7:18 AM, Adam Wulkiewicz via Boost <boost@lists.boost.org> wrote:
W dniu 16.07.2020 o 07:36, Marshall Clow via Boost pisze:
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 some bugfixes: https://github.com/boostorg/geometry/compare/master...develop
There are four commits there. The first two are not a problem. The third one is a significant chunk of code. The fourth one is a lot of changes, but appears to be mostly just code rearrangement. If you’re happy with the test results, and you think that these changes are suitable for “after the beta” (especially the third change), then go ahead. — Marshall
participants (13)
-
Adam Wulkiewicz -
Alexander Grund -
Andrey Semashev -
Antony Polukhin -
Glen Fernandes -
Ion Gaztañaga -
Jeff Garland -
Marc Glisse -
Marshall Clow -
Niall Douglas -
Peter Dimov -
Richard Hodges -
Vinnie Falco