- Boost - lists.boost.org

Re: [boost] [release] 1.75.0 post-beta merges
by Peter Dimov 26 Nov '20

26 Nov '20

>>>> ...failed testing.capture-output >>>> ..\..\bin.v2\libs\filesystem\test\operations_unit_test.test\clang-win-10.0.0\release\threading-multi\operations_unit_test.run... ... > This looks like a Clang x86 codegen bug. The compiler returns the > `file_status` from `get_status` on the stack and then overwrites it with > `push` instructions for some reason. > > Not the first x86 clang-cl problem. I'll upgrade from 10.0 to 11.0 to see > if it's fixed. Still not fixed in 11.0.

2 3

[random] Merging to master for 1.75 release
by Edward Diener 25 Nov '20

25 Nov '20

Is there any possibility of merging 'develop' to 'master' for the random library for the 1.75 release ? The 'master' branch has not been updated for 2 years, or since the 1.70 release. While I am not claiming all invaluable fixes I know my fix for Embarcadero C++ clang-based support and another fix for correctly auto-linking random_device is among the 'develop' branch fixes which have never made it to the 'master' branch.

4 9

Submitting release notes
by Andrzej Krzemienski 25 Nov '20

25 Nov '20

I am sorry for this silly question, but can someone remind me, where we file PR-s with library release notes? Can someone point me to the place where this is documented? Regards, &rzej;

2 1

[leaf] Request to merge bug fix to master for 1.75 release
by Emil Dotchevski 24 Nov '20

24 Nov '20

I'm requesting permission to merge a bug fix by vector-of-bool in LEAF which makes it work correctly with std::system_error: https://github.com/boostorg/leaf/pull/15/commits/efc56d1c703777fea4fef2bd24… (There is a minor related change on top of this PR, but this bug fix is the important change in behavior. Note that LEAF is a new library in 1.75).

2 1

[release] Boost 1.75.0 Beta 1 Release Candidate 2
by Marshall Clow 17 Nov '20

17 Nov '20

The second release candidates for the 1.75.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/> The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

9 23

[release] Fixing Boost.Rational and boost/operators.hpp infinite loop in C++20 by 1.75
by Glen Fernandes 16 Nov '20

16 Nov '20

We have a problem with Boost.Rational and <boost/operators.hpp> in Boost.Utility in C++20 standards mode. I've fixed Boost.Rational in develop. Relevant GitHub issues: 1. https://github.com/boostorg/rational/issues/43 2. https://github.com/boostorg/utility/issues/65 My fix for Boost.Rational that I will merge to master for the 1.75 release: https://github.com/boostorg/rational/pull/45 The root cause is the same. C++20 adds new language rules that implicitly generate some operators, and the current implementations result in an infinite loop. (In both cases an equality operator ends up calling itself recursively). GCC does emit a warning diagnostic in C++20 mode, but as usual these tend to be unnoticed at build time. ../../boost/rational.hpp:779:16: warning: in C++20 this comparison calls the current function recursively with reversed arguments 779 | return a == b; | ~~^~~~ So this issue was found by three independent users of Rational (one who reported a Github issue, the other who complained on Reddit, and a third that tried running the Rational unit tests with GCC10 and found two failures). <boost/operators.hpp> in Boost.Utility still needs a fix for C++20 mode, but it has an active maintainer unlike Rational. The GitHub issue for it was closed (I've reopened it) because it was assumed to be a defect in the standard and one that vendors would fix. We did have some discussion on the C++ standard committee reflector about this, however - whatever the future change to the standard is - GCC and Clang with -std=c++20 that implement these rules have already been released and users are using it, so we should fix this in Boost 1.75. Glen

2 1

Re: [boost] [release] 1.75.0 post-beta merges
by Glen Fernandes 16 Nov '20

16 Nov '20

Robert Ramey wrote: > request permission to sync changes in develop into master for > two libraries: serialization and safe_numerics. They've been ready for > some time, I just forgot to do it in time. Go ahead. Glen

1 0

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 14 Nov '20

14 Nov '20

Boost release 1.75.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/> The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_75_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

Boost.Exception regression in 1.75.0 beta 1
by Niall Douglas 14 Nov '20

14 Nov '20

If you diagnose the test failures (which are present across all compilers) in https://www.boost.org/development/tests/develop/developer/outcome.html which report failures of the form: ``` unknown location(0): fatal error: in "works_outcome": Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: struct boost::wrapexcept<class boost::exception_ptr> libs\outcome\test\tests\core-outcome.cpp(173): last checkpoint *** 1 failure is detected in the test module "Outcome" ``` The cause is test code such as: ``` boost::system::error_code ec(5, boost::system::system_category()); auto e = boost::copy_exception(boost::system::system_error(ec)); // NOLINT outcome<int> m(e); BOOST_CHECK_THROW(m.value(), boost::system::system_error); ``` Outcome calls boost::rethrow_exception() to rethrow the exception_ptr. boost::rethrow_exception() is not rethrowing the boost::system::system_error held within the boost::exception_ptr. It is throwing instead boost::wrapexcept<class boost::exception_ptr>. This causes BOOST_CHECK_THROW() to not correctly trap the type of exception thrown, and thus the test fails. boost::wrapexcept<E> inherits from E. It seems to me therefore that catching a const E& ought to catch throws of boost::wrapexcept<E>, and therefore this code is correct. I double checked this at https://wandbox.org/permlink/n9Wjb5cPpfHEFalp, and indeed it works as expected. However, obviously enough this is failing, and it was not failing in Boost 1.74, so this is a regression. I am stumped as to the exact cause. This affects all platforms, POSIX, Windows, clang, GCC and MSVC. Niall

3 2

permission to merge fix
by Oliver Kowalke 08 Nov '20

08 Nov '20

Do I get permission to merge a fix related to boostorg/fiber#264 <https://github.com/boostorg/fiber/issues/264> into master? Oliver

3 3