On Sun, Nov 15, 2020 at 7:06 PM Niall Douglas wrote:

On 15/11/2020 19:05, 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.

boostorg/outcome now has the fix for the exception throw failure on master branch. I'll watch the regression matrix, see if it now goes all green.

Permission for merges to master are required at this point. You should commit to develop, let he tests cycle, and then request permission to merge to master. Glen

On Wednesday, November 18, 2020, Niall Douglas via Boost < boost@lists.boost.org> wrote:

On 16/11/2020 01:13, Glen Fernandes wrote:

...

On Sun, Nov 15, 2020 at 7:06 PM Niall Douglas wrote:

...

On 15/11/2020 19:05, 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.

boostorg/outcome now has the fix for the exception throw failure on master branch. I'll watch the regression matrix, see if it now goes all green.

Permission for merges to master are required at this point. You should commit to develop, let he tests cycle, and then request permission to merge to master.

Looks like someone git reset master branch to undo my fix. Thank you to whomever did that.

May I have permission to merge the fix for the exception throw failure to master branch?

Go ahead. Glen

On Monday, November 16, 2020, Richard Hodges wrote:

I have some minor Beast fixes that have been successfully tested on develop.

Seeking permission to merge to master.

Go ahead. Glen

On Mon, Nov 16, 2020 at 12:57 PM Vinnie Falco via Boost wrote:

On Sun, Nov 15, 2020 at 11:05 AM 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.

I'd like to merge these three Very Stable Commits to master. Ermm.. I mean "main." Or whatever it is called these days.

Disable unreachable code warning https://github.com/boostorg/json/commit/f8d2c7617e8757221475904223771f5e7150...

gcc 4.7 is not supported https://github.com/boostorg/json/commit/512a8478de00a69eda9dfa8ea34c91f274b3...

Looks fine to me.

Add GH issue template https://github.com/boostorg/json/commit/76ee8891d20167a2192aa594b7d2c702be2b...

You don't need permission to merge things like this. Glen

John Maddock wrote:

There is also this small patch to type_traits which um... I confess I forgot all about for this release:

https://github.com/boostorg/type_traits/commit/c6c7ff164789e7ca1d71745714cb2...

Set up a Travis merge reminder and you won't be forgetting things. https://github.com/pdimov/merge-reminder https://travis-ci.org/github/pdimov/merge-reminder

On Nov 16, 2020, at 8:48 PM, Vinnie Falco wrote:

...

Can we please squeak this in? It is an embarrassing omission noticed by a tester:

Add value::is_integral https://github.com/boostorg/json/commit/099a82957a75bf088a8bc45a379f81b3c666...

This addition is of questionable utility (and so is the practice of adding features post-beta.) JSON as a format doesn't distinguish between 100 and 1e2, but this facility encourages writing code that accepts the former and rejects the latter, even though they are equivalent in principle.

On Wed, 18 Nov 2020 at 16:55, Vinnie Falco via Boost wrote:

On Sun, Nov 15, 2020 at 11:05 AM 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.

I would also like to merge these two (one updates the doc toolchain, the other updates JSON's doc config file)

< https://github.com/boostorg/docca/commit/36187e2c964f000c259cca32b48371fe068...

...

If this one goes in, I will also need to commit this one: < https://github.com/boostorg/beast/pull/2123/commits/0633e8a55d0bb4161c3f9d90...

< https://github.com/boostorg/json/commit/bfacd2bfd8ea563f7a93790ab45fa4631c96...

...

And this one, which fixes the problem where shared libraries can't be built in standalone:

< https://github.com/boostorg/json/commit/9e67899cd5ef017e02435809481581e8d819...

...

Thanks!

_______________________________________________ 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, Nov 18, 2020 at 9:38 AM Glen Fernandes via Boost wrote:

This is a PR to develop, which you don't need permission to merge.

What he's saying is that this change will also need to go into the master branch when the docca changes are merged to master. Thanks

On Friday, November 20, 2020, Andrey Semashev wrote:

I would like to merge these commits to Boost.Atomic master:

https://github.com/boostorg/atomic/commit/e873eb15969d610aa8 94df6581786ef6a6365b93

https://github.com/boostorg/atomic/commit/0835f7cdf4a80136cd ca1aafac42fd175274bb74

https://github.com/boostorg/atomic/commit/ea5911a413a698f5b7 a2db24a705bcc358611d0e

I have tested these changes on a local AArch64 QEMU VM (for both AARch32 and AArch64 targets) and locally for x86 (which is unaffected by these changes anyway). AppVeyor CI has passed. Travis CI job is hanging scheduled for more than one day, and it doesn't look like it'll start any time soon.

I tested your develop on my Travis: https://travis-ci.org/github/glenfe/boost.atomic/builds/745027036 Go ahead and merge. Glen

On Nov 23, 2020, at 10:14 AM, John Maddock via Boost wrote:

On 15/11/2020 19:05, 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

A quick heads up that I've merged some documentation changes to regex, which I believe is allowed under the release policy?

Thanks for the heads-up, and you are correct - approval is not necessary — Marshall

Andrey Semashev wrote:

I'd like to merge these commits to Boost.Filesystem master:

https://github.com/boostorg/filesystem/commit/6c2bf50c3a678a87ccbf45bfc275ff...

Fixes space() operation not failing on Windows when a non-existing path is specified.

https://github.com/boostorg/filesystem/commit/9cab675b71e98706886a87afe7c19e...

Resolves spurious symlink test failures.

AppVeyor CI has passed. Travis CI on boostorg is hanging, but has passed on my local fork. Also tested locally on Linux.

FWIW I ran the tests on the current develop branch locally on Windows using b2 -j6 test toolset=msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1,msvc-14.2,clang-win variant=debug,release There was a single failure, clang-win in release, ...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... but it's also present on the master branch, so it's not a regression.

Andrey Semashev wrote:

On 11/26/20 6:09 PM, Peter Dimov via Boost wrote:

...

FWIW I ran the tests on the current develop branch locally on Windows using

b2 -j6 test toolset=msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1,msvc-14.2,clang-win variant=debug,release

There was a single failure, clang-win in release,

...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... but it's also present on the master branch, so it's not a regression.

Could you provide more details for the error?

The output from the test is: testing.capture-output ..\..\bin.v2\libs\filesystem\test\operations_unit_test.test\clang-win-10.0.0\release\threading-multi\operations_unit_test.run ====== BEGIN OUTPUT ====== BOOST_WINDOWS_API is defined BOOST_FILESYSTEM_DECL=__attribute__((__dllimport__)) BOOST_SYMBOL_VISIBLE= current_path() is C:\boost-git\develop\libs\filesystem argv[1] is 'C:\boost-git\develop\libs\filesystem\test', changing current_path() to it current_path() is C:\boost-git\develop\libs\filesystem\test temp_dir is C:\boost-git\develop\libs\filesystem\test\..\op-unit_test-630b-eaad-7f54 file_status test... status(".") permissions are 666 symlink_status(".") permissions are 666 query test... directory_iterator_test... test\operations_unit_test.cpp(133): test failed test\operations_unit_test.cpp(134): test failed test\operations_unit_test.cpp(135): test failed test\operations_unit_test.cpp(136): test failed directory_iterator_test complete recursive_directory_iterator_test... test\operations_unit_test.cpp(194): test failed test\operations_unit_test.cpp(195): test failed test\operations_unit_test.cpp(196): test failed test\operations_unit_test.cpp(197): test failed recursive_directory_iterator_test complete operations test... directory_entry test... directory_entry overload test... error handling test... as expected, attempt to get size of non-existent file threw a filesystem_error what() returns boost::filesystem::file_size: The system cannot find the file specified: "no-such-file" string_file_tests... "b8ea-43a3-e9da-feda" "foo-0b9d7-e3997-bar" "foo-5fc17-60a20-37b65-37a64-f6928-ab2cd-04714-94cf-bar" "foo-f04d2-68d9f-9dcef-8e447-d0378-bf2fa-a6491-d3530-bar" testing complete post-test removal of "C:\boost-git\develop\libs\filesystem\test\..\op-unit_test-630b-eaad-7f54" post-test removal complete 8 errors detected. EXIT STATUS: 8 ====== END OUTPUT ======

Andrey Semashev wrote:

...

...

...

There was a single failure, clang-win in release,

...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... but it's also present on the master branch, so it's not a regression.

Could you provide more details for the error?

The output from the test is:

Does it also fail when you run tests sequentially? I.e. just one compiler and just one variant, with -j1?

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.

On Sun, Nov 29, 2020 at 2:01 PM Adam Wulkiewicz wrote:

W dniu 27.11.2020 o 00:53, Adam Wulkiewicz pisze:

...

I'd like to merge the following bugfixes and workarounds: https://github.com/boostorg/geometry/compare/master...awulkiew:master-includ...

This is a part of the change I plan to merge. It only contains files from include directory. I extracted it for your convenience. I also plan to update tests and documentation but it's not required to ask for permission in this case. I pushed it to my repository instead of boostorg submodule to not introduce this temporary branch into the main repo.

These look like a lot of changes, and not all of them are new since the beta release. (i.e. As if they should have been merged to master before the beta but were forgotten). How much are fixes versus new features that could wait until 1.76? Glen

On Sun, Nov 29, 2020 at 3:13 PM Adam Wulkiewicz via Boost wrote:

...

...

W dniu 27.11.2020 o 00:53, Adam Wulkiewicz pisze:

...

I'd like to merge the following bugfixes and workarounds: https://github.com/boostorg/geometry/compare/master...awulkiew:master-includ...

This is a part of the change I plan to merge. It only contains files from include directory. I extracted it for your convenience. I also plan to update tests and documentation but it's not required to ask for permission in this case. I pushed it to my repository instead of boostorg submodule to not introduce this temporary branch into the main repo. These look like a lot of changes, and not all of them are new since

On Sun, Nov 29, 2020 at 2:01 PM Adam Wulkiewicz wrote: the beta release. (i.e. As if they should have been merged to master before the beta but were forgotten). How much are fixes versus new features that could wait until 1.76? All of them are bugfixes or workarounds. They were not merged sooner because the corresponding PRs were merged into develop after beta since

W dniu 29.11.2020 o 20:08, Glen Fernandes pisze: they had to be reviewed. Look at the dates of "Merge pull request ..." commits.

Technically this commit (https://github.com/boostorg/geometry/commit/dbd0bb62dfce31caea5275085bf63e86...) introduces new, optional trait but without it there is a breaking change and I prefer to avoid releasing it as it is. After waiting long for reviews I briefly moved it to 1.76 but I went back to this breaking change while working on workarounds for Clang and assessed that the issue is potentially worse than I initially thought (see: https://github.com/boostorg/geometry/pull/747).

This bugfix could wait https://github.com/boostorg/geometry/commit/42bd7cfe95c079aabb3c3357edf370d7... but it looks harmless to me.

Adam

Got it. OK to merge (all of them, including 42bd7cfe). Glen

On Mon, Nov 30, 2020 at 6:56 PM Adam Wulkiewicz via Boost wrote:

W dniu 29.11.2020 o 21:19, Glen Fernandes pisze:

...

Got it. OK to merge (all of them, including 42bd7cfe).

Thanks! I'd like to merge one more trivial workaround: https://github.com/boostorg/geometry/commit/d2d3a7954a0006af308fb87e5485750d...

That removes it for MSVC 2015 v14.0 (i.e. 1900 or older), but I was under the impression that even MSVC 2017 v15.0 (i.e. 1910) is not enough. I thought the constexpr issues were fixed with MSVC 2017 v15.8 or higher (i.e. 1915). For that reason BOOST_NO_CXX14_CONSTEXPR is also defined for all versions of MSVC below 2017 v15.8 (1915). Glen Glen

On Wed, Dec 2, 2020 at 4:27 PM Adam Wulkiewicz wrote:

wt., 1 gru 2020 o 01:34 Glen Fernandes napisał(a):

...

On Mon, Nov 30, 2020 at 6:56 PM Adam Wulkiewicz via Boost wrote:

...

W dniu 29.11.2020 o 21:19, Glen Fernandes pisze:

...

Got it. OK to merge (all of them, including 42bd7cfe).

Thanks! I'd like to merge one more trivial workaround: https://github.com/boostorg/geometry/commit/d2d3a7954a0006af308fb87e5485750d...

That removes it for MSVC 2015 v14.0 (i.e. 1900 or older), but I was under the impression that even MSVC 2017 v15.0 (i.e. 1910) is not enough. I thought the constexpr issues were fixed with MSVC 2017 v15.8 or higher (i.e. 1915).

For that reason BOOST_NO_CXX14_CONSTEXPR is also defined for all versions of MSVC below 2017 v15.8 (1915).

I think your understanding is technically correct. AFAIU it's because the general-purpose Boost.Config macro has to work in all cases and accommodate for various quirks of different compilers. However in this particular case this workaround seems to be enough. All of our tests compile, with this workaround even with VS2015.

If you're testing 2017 v15.0 (not 15.8+) and it passes, then using >= 1910 is fine. You should make it BOOST_MSVC not _MSC_VER since I'm sure here you mean actual MSVC and not anything else (cygwin, mingw or whatever else) that defines it to pretend to be MSVC. Glen

W dniu 01.12.2020 o 00:55, Adam Wulkiewicz pisze:

W dniu 29.11.2020 o 21:19, Glen Fernandes pisze:

...

Got it. OK to merge (all of them, including 42bd7cfe).

Thanks! I'd like to merge one more trivial workaround: https://github.com/boostorg/geometry/commit/d2d3a7954a0006af308fb87e5485750d...

May I? :) Adam

On Dec 1, 2020, at 1:41 PM, Richard Hodges via Boost wrote:

I would like to merge the following commits:

Fixes a regression that prevents the test stream from working as a next_layer of asio::ssl::stream. https://github.com/boostorg/beast/commit/822722c6c3a1a142eab21058b02d202d221...

This looks like a test change. You don’t need permission to merge changes to tests.

Updates the version number as per our release policy. https://github.com/boostorg/beast/commit/393b11be81226af487083fc5b5c4a612d48...

This is fine - go ahead. — Marshall