[release] 1.72.0 post-beta merges

Michael Caisse

21 Nov 2019 21 Nov '19

4:37 p.m.

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/boost/wiki/Releases%3A-Beta-Merge-Policy

Show replies by date

Raffi Enficiaud

21 Nov 21 Nov

8:01 p.m.

On 21.11.19 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy

I would like to merge this changes to master https://github.com/boostorg/test/compare/ed04b2a5e64e428755986b52d84e002723f... Tests green. Thanks! Raffi

Michael Caisse

23 Nov 23 Nov

7:19 p.m.

On 11/21/19 12:01, Raffi Enficiaud via Boost wrote:

...

On 21.11.19 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy

I would like to merge this changes to master

https://github.com/boostorg/test/compare/ed04b2a5e64e428755986b52d84e002723f...

Tests green.

Do we have testers that disable RTTI? The change_log notes indicate that there is better "diagnostics for boost::exception and no rtti mode". Do you know when this improvement entered Boost? michael -- Michael Caisse Ciere Consulting ciere.com

Raffi Enficiaud

24 Nov 24 Nov

10:19 a.m.

On 23.11.19 20:19, Michael Caisse via Boost wrote:

...

On 11/21/19 12:01, Raffi Enficiaud via Boost wrote:

...
On 21.11.19 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy

I would like to merge this changes to master

https://github.com/boostorg/test/compare/ed04b2a5e64e428755986b52d84e002723f...

Tests green.

Do we have testers that disable RTTI?

The change_log notes indicate that there is better "diagnostics for boost::exception and no rtti mode". Do you know when this improvement entered Boost?

Thanks for the feedback. If this merge contains changes that can be problematic, I can split it up and get the bugfix "# [github_issue 206] compile-time disabled test not correctly handled by junit log" alone instead. Concerning the RTTI, I do not know about any runners. Maybe somebody has an idea? The change itself forwards the creation of the error message/diagnostic to boost::exception, now unconditionally to the RTTI support. The error message is created by "boost::diagnostic_information" in /libs/exception/include/boost/exception/diagnostic_information.hpp There I can see several #ifndef BOOST_NO_RTTI / #endif and my understanding is that boost::exception library already handles the NO_RTTI case better than boost.test. All in all I believe this change is safe. Let me know what you think. If this is too risky, let me know if I can merge the other bugfix. Best, Raffi

...

michael

Mateusz Loskot

23 Nov 23 Nov

2:42 p.m.

On Thu, 21 Nov 2019 at 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy

In GIL, we'd like to merge a set of seven commits with minor and documentation changes [1] that we believe do not require request for permission. [1] https://lists.boost.org/boost-gil/2019/11/0353.php There is one change we are debating [2] if it needs permission or not: * Remove include/boost/gil/version.hpp file as unused https://github.com/boostorg/gil/commit/84b155630d1d59d604ba9c1e083c7d8ae8097... [2] https://lists.boost.org/boost-gil/2019/11/0354.php The boost/gil/version.hpp was added in Boost 1.68 and we are finding it useless and confusing, so we've decided to remove it. We don't think there has been any wide use of or dependence on this header, so we consider it safe to be removed at any time. Can we merge the removal of the boost/gil/version.hpp as post-beta merge now? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Michael Caisse

7:10 p.m.

On 11/23/19 06:42, Mateusz Loskot via Boost wrote:

...

On Thu, 21 Nov 2019 at 17:37, Michael Caisse via Boost wrote:

...

...

In GIL, we'd like to merge a set of seven commits with minor and documentation changes [1] that we believe do not require request for permission.

Correct. Merge away.

...

Can we merge the removal of the boost/gil/version.hpp as post-beta merge now?

Please feel free to merge. I would like to see mention of it in the release notes for GIL. -- Michael Caisse Ciere Consulting ciere.com

Mateusz Loskot

8:29 p.m.

On Sat, 23 Nov 2019 at 20:10, Michael Caisse via Boost wrote:

...

On 11/23/19 06:42, Mateusz Loskot via Boost wrote:

...
On Thu, 21 Nov 2019 at 17:37, Michael Caisse via Boost wrote:

In GIL, we'd like to merge a set of seven commits with minor and documentation changes [1] that we believe do not require request for permission.

Correct. Merge away.

Done.

...

...
Can we merge the removal of the boost/gil/version.hpp as post-beta merge now?

Please feel free to merge. I would like to see mention of it in the release notes for GIL.

Done, with the notes update submitted in https://github.com/boostorg/website/pull/460 Thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Vinnie Falco

25 Nov 25 Nov

10:54 p.m.

On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse via Boost wrote:

...

The master branch is is now open for post-beta merges

Boost.Asio still has a defect here: https://github.com/boostorg/asio/blob/9254ec55a3d90019cc3223b018bb38b5c1a49d... It should have "typename" This fails on some flavors of MSVC: https://ci.appveyor.com/project/vinniefalco/beast/history I thought this was fixed in this commit: https://github.com/boostorg/asio/commit/529ce8dec4a16b8745fe596875e133dc022d... But it wasn't. I believe this has been reported twice: https://github.com/boostorg/asio/issues/299 https://github.com/chriskohlhoff/asio/issues/436 Beast gets a compilation error in some versions of MSVC. Thanks

Vinnie Falco

26 Nov 26 Nov

3:26 p.m.

On Mon, Nov 25, 2019 at 2:54 PM Vinnie Falco wrote:

...

Boost.Asio...

A Slack user also reports this:

...

was playing around with 1.72 beta asio, and it looks like this incorrectly concludes that recent msvc with /std:c++1[47] has no ret type deduction: https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/conf... the existing test i believe would require msvc to run with /Zc:__cplusplus which is still not the default. a fix that works on my end is adding

# elif defined(__cpp_return_type_deduction) && __cpp_return_type_deduction >= 201304 # define ASIO_HAS_RETURN_TYPE_DEDUCTION 1 include/boost/asio/detail/config.hpp:318 #if !defined(BOOST_ASIO_HAS_RETURN_TYPE_DEDUCTION)

We should probably fix this along with the other problem I mentioned earlier. Thanks

Vinnie Falco

28 Nov 28 Nov

1:36 p.m.

On Mon, Nov 25, 2019 at 2:54 PM Vinnie Falco wrote:

...

Boost.Asio still has a defect here: ...https://github.com/boostorg/asio/blob/9254ec55a3d90019cc3223b018bb38b5c1a49d...

Still a problem Thanks

Adam Wulkiewicz

29 Nov 29 Nov

9:39 p.m.

W dniu 21.11.2019 o 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy I'd like to merge several fixes for Geometry. Here are the changes done in include directory only: https://github.com/boostorg/geometry/compare/master...bg-prepare-include

In addition to the above I'd like to merge fixes and additional test cases in test directory but AFAIU I don't need a permission for that so I didn't include it in the diff above for your convenience. I also have a question regarding the policy. In the section: *"**Documentation fixes and other minor changes not affecting code.**"*, the policy states: /> //Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission./ AFAIK no other library depends on Geometry (see: https://pdimov.github.io/boostdep-report/boost-1.71.0/geometry.html *"Reverse dependencies"* section at the bottom). Does it mean we do not have to ask for permission for fixes like the ones above? Adam

Marshall Clow

2 Dec 2 Dec

3:49 p.m.

On Fri, Nov 29, 2019 at 1:40 PM Adam Wulkiewicz via Boost < boost@lists.boost.org> wrote:

...

W dniu 21.11.2019 o 17:37, Michael Caisse 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/boost/wiki/Releases%3A-Beta-Merge-Policy> I'd like to merge several fixes for Geometry. Here are the changes done in include directory only: https://github.com/boostorg/geometry/compare/master...bg-prepare-include

In addition to the above I'd like to merge fixes and additional test cases in test directory but AFAIU I don't need a permission for that so I didn't include it in the diff above for your convenience.

Go ahead. -- Marshall

...

I also have a question regarding the policy. In the section: *"**Documentation fixes and other minor changes not affecting code.**"*, the policy states:

/> //Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission./

AFAIK no other library depends on Geometry (see: https://pdimov.github.io/boostdep-report/boost-1.71.0/geometry.html *"Reverse dependencies"* section at the bottom). Does it mean we do not have to ask for permission for fixes like the ones above?

Vinnie Falco

3 Dec 3 Dec

3:43 p.m.

On Mon, Dec 2, 2019 at 7:49 AM Marshall Clow via Boost wrote:

...

...

Two Asio problems outstanding: 1. A syntax error persists 2. Missing release notes Regards

Vinnie Falco

3:47 p.m.

On Tue, Dec 3, 2019 at 7:43 AM Vinnie Falco wrote:

...

1. A syntax error persists

boostorg/asio was just updated today, I see the possible fix for this error and I am testing it on Appveyor now. Thanks

Marshall Clow

4:01 p.m.

On Tue, Dec 3, 2019 at 7:48 AM Vinnie Falco wrote:

...

On Tue, Dec 3, 2019 at 7:43 AM Vinnie Falco wrote:

...
1. A syntax error persists

boostorg/asio was just updated today, I see the possible fix for this error and I am testing it on Appveyor now.

Glad you're on top of it, Thanks. -- Marshall

Vinnie Falco

5:42 p.m.

On Tue, Dec 3, 2019 at 8:01 AM Marshall Clow wrote:

...

Glad you're on top of it,

The compilation error with asio is fixed. Still no asio release notes. Thanks

Vinnie Falco

4 Dec 4 Dec

8:36 p.m.

On Tue, Dec 3, 2019 at 9:42 AM Vinnie Falco wrote:

...

The compilation error with asio is fixed. Still no asio release notes.

Unfortunately, the asio fix is only in the develop branch. The master branch is still broken, and there are still no release notes. Regards

Marshall Clow

5 Dec 5 Dec

4:47 a.m.

On Wed, Dec 4, 2019 at 12:36 PM Vinnie Falco wrote:

...

On Tue, Dec 3, 2019 at 9:42 AM Vinnie Falco wrote:

...
The compilation error with asio is fixed. Still no asio release notes.

Unfortunately, the asio fix is only in the develop branch. The master branch is still broken, and there are still no release notes.

Looks like they're there now. Is your problem fixed? -- Marshall

Vinnie Falco

3 p.m.

On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow wrote:

...

Looks like they're there now. Is your problem fixed?

It does not look like it is fixed. A rebuild of the beast master branch still fails on Appveyor. I am trying again in case the failure was spurious. Thanks

Vinnie Falco

5:07 p.m.

On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow wrote:

...

Looks like they're there now. Is your problem fixed?

I rebuilt the commit on Appveyor and now it is green, so the problem is resolved: https://ci.appveyor.com/project/vinniefalco/beast/builds/29339563 Thanks

Marshall Clow

5:31 p.m.

On Thu, Dec 5, 2019 at 9:07 AM Vinnie Falco wrote:

...

On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow wrote:

...
Looks like they're there now. Is your problem fixed?

I rebuilt the commit on Appveyor and now it is green, so the problem is resolved:

https://ci.appveyor.com/project/vinniefalco/beast/builds/29339563

That's encouraging; thanks for the update. -- Marshall

Tobias Loew

3:16 p.m.

Could someone please have a look at http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16... cause it's a showstopper for the latest VS 2019 (16.4.0). It's not an error introduced in 1.72 but already there for a long time, and now the latest MSVC version produces an error on that MSVC-workaround. thanks -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

Daniela Engert

4:15 p.m.

Hi Tobias! Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost:

...

Could someone please have a look at http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16... cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time, and now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again. Ciao Dani

Tom Kent

6 Dec 6 Dec

9:35 p.m.

On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost < boost@lists.boost.org> wrote:

...

Hi Tobias!

Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost:

...
Could someone please have a look at

http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

...
cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time, and now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Ciao Dani

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary. Tom

Daniela Engert

7 Dec 7 Dec

6:51 a.m.

Hi Tom! Am 06.12.2019 um 22:35 schrieb Tom Kent via Boost:

...

On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost < boost@lists.boost.org> wrote:

...
Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost: http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

...
cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time, and now the latest MSVC version produces an error on that MSVC-workaround. I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary.

It definitely was compiling just fine until 16.3.7, because this was the version that I have been using as my main compiler at work before switching to 16.4.0 two days ago. Our ubiquitously used logging library depends on Boost.Log which suddenly became affected from the workaround in Boost.Proto no longer compiling. Unfortunately, I've never compiled our production code with any of the 16.4-pre versions. I only did with my C++20 Modules experiments during my talk preparations, but I noticed that despite the seemingly minor bump 16.3 -> 16.4, the compiler learned a couple of new features (e.g. concepts, the new C++20 syntax). So, until there is a thorough exploration with all Boost libs compiled with msvc 16.4.0 in all 4 modes (32/64, debug/release), there might lurk other surprises as well. Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

Tom Kent

8 Dec 8 Dec

12:20 p.m.

On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert wrote:

...

Hi Tom!

Am 06.12.2019 um 22:35 schrieb Tom Kent via Boost:

On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost wrote:

Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost:

http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time,

and

now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary.

It definitely was compiling just fine until 16.3.7, because this was the version that I have been using as my main compiler at work before switching to 16.4.0 two days ago. Our ubiquitously used logging library depends on Boost.Log which suddenly became affected from the workaround in Boost.Proto no longer compiling.

Unfortunately, I've never compiled our production code with any of the 16.4-pre versions. I only did with my C++20 Modules experiments during my talk preparations, but I noticed that despite the seemingly minor bump 16.3 -> 16.4, the compiler learned a couple of new features (e.g. concepts, the new C++20 syntax). So, until there is a thorough exploration with all Boost libs compiled with msvc 16.4.0 in all 4 modes (32/64, debug/release), there might lurk other surprises as well.

Ciao Dani

I'm not sure I can reproduce this. I'm trying to run with four different configs: based on visual studio build tools 16.3.x toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest based on visual studio build tools 16.4.0 toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest running in proto ..\..\b2 [config from above] test works fine for all versions....so this bug isn't covered by a test I'm guessing. Running in log ..\..\b2 [config from above] test causes the log build to fail for both 16.3 and 16.4 for the configurations that use cxxflags=/std:c++latest. This can be seen in the regression tests for boost.log: https://www.boost.org/development/tests/develop/developer/log.html https://www.boost.org/development/tests/master/developer/log.html teeks99-07-v16[m|d]-64onAMD64 is the normal msvc-14.2 teeks99-07-v16[m|d]l-64onAMD64 is the msvc-14.2 with cxxflags=/std:c++latest The error looks something like this (and goes on for a bit) D:\boost\libs\log>..\..\b2 toolset=msvc-14.2 cxxflags=/std:c++latest test Performing configuration checks - default address-model : 32-bit (cached) - default architecture : x86 (cached) - symlinks supported : yes (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - has_icu builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - message-compiler : yes (cached) ...patience... ...patience... ...patience... ...patience... ...patience... ...found 23437 targets... ...updating 334 targets... compile-c-c++ ..\..\bin.v2\libs\log\build\msvc-14.2\debug\threadapi-win32\threading-multi\syslog_backend.obj syslog_backend.cpp D:\boost\boost/asio/async_result.hpp(44): error C2062: type 'bool' unexpected D:\boost\boost/asio/async_result.hpp(45): error C2143: syntax error: missing ';' before '{' D:\boost\boost/asio/async_result.hpp(45): error C2447: '{': missing function header (old-style formal list?) D:\boost\boost/asio/async_result.hpp(56): error C7568: argument list missing after assumed function template 'callable_with' D:\boost\boost/asio/async_result.hpp(58): note: see reference to class template instantiation 'boost::asio::detail::is_co I tried a `D:\boost\libs\proto> git checkout ef2e94fe299449c4b23f305a854de0b5b48248be` and had the exact same results as above. Can you provide some steps to minimally reproduce this issue? Thanks, Tom

Edward Diener

4:04 p.m.

On 12/8/2019 7:20 AM, Tom Kent via Boost wrote:

...

On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert wrote:

...
Hi Tom!

Am 06.12.2019 um 22:35 schrieb Tom Kent via Boost:

On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost wrote:

Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost:

http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time,

and

now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary.

It definitely was compiling just fine until 16.3.7, because this was the version that I have been using as my main compiler at work before switching to 16.4.0 two days ago. Our ubiquitously used logging library depends on Boost.Log which suddenly became affected from the workaround in Boost.Proto no longer compiling.

Unfortunately, I've never compiled our production code with any of the 16.4-pre versions. I only did with my C++20 Modules experiments during my talk preparations, but I noticed that despite the seemingly minor bump 16.3 -> 16.4, the compiler learned a couple of new features (e.g. concepts, the new C++20 syntax). So, until there is a thorough exploration with all Boost libs compiled with msvc 16.4.0 in all 4 modes (32/64, debug/release), there might lurk other surprises as well.

Ciao Dani

I'm not sure I can reproduce this. I'm trying to run with four different configs:

based on visual studio build tools 16.3.x toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest based on visual studio build tools 16.4.0 toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest

running in proto ..\..\b2 [config from above] test works fine for all versions....so this bug isn't covered by a test I'm guessing.

Running in log ..\..\b2 [config from above] test

causes the log build to fail for both 16.3 and 16.4 for the configurations that use cxxflags=/std:c++latest. This can be seen in the regression tests for boost.log: https://www.boost.org/development/tests/develop/developer/log.html https://www.boost.org/development/tests/master/developer/log.html

teeks99-07-v16[m|d]-64onAMD64 is the normal msvc-14.2 teeks99-07-v16[m|d]l-64onAMD64 is the msvc-14.2 with cxxflags=/std:c++latest

The error looks something like this (and goes on for a bit)

D:\boost\libs\log>..\..\b2 toolset=msvc-14.2 cxxflags=/std:c++latest test Performing configuration checks

- default address-model : 32-bit (cached) - default architecture : x86 (cached) - symlinks supported : yes (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - has_icu builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - message-compiler : yes (cached) ...patience... ...patience... ...patience... ...patience... ...patience... ...found 23437 targets... ...updating 334 targets... compile-c-c++ ..\..\bin.v2\libs\log\build\msvc-14.2\debug\threadapi-win32\threading-multi\syslog_backend.obj syslog_backend.cpp D:\boost\boost/asio/async_result.hpp(44): error C2062: type 'bool' unexpected D:\boost\boost/asio/async_result.hpp(45): error C2143: syntax error: missing ';' before '{' D:\boost\boost/asio/async_result.hpp(45): error C2447: '{': missing function header (old-style formal list?) D:\boost\boost/asio/async_result.hpp(56): error C7568: argument list missing after assumed function template 'callable_with' D:\boost\boost/asio/async_result.hpp(58): note: see reference to class template instantiation 'boost::asio::detail::is_co

Testing on the 'develop' branch: For what it is worth the Boost log problem is because msvc-14.2 in C20 mode rejects the syntax: 'concept bool' etc. when __cpp_concepts is 1. My testing of asio with msvc-14.2 in c20 mode also fails for the same reason.

...

I tried a `D:\boost\libs\proto> git checkout ef2e94fe299449c4b23f305a854de0b5b48248be` and had the exact same results as above.

Can you provide some steps to minimally reproduce this issue?

Daniela Engert

5:35 p.m.

Hi Tom! Am 08.12.2019 um 13:20 schrieb Tom Kent:

...

On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert mailto:dani@ngrt.de> wrote:

Hi Tom!

Am 06.12.2019 um 22:35 schrieb Tom Kent via Boost:

...
On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost < boost@lists.boost.org mailto:boost@lists.boost.org> wrote:

...
Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost: http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

...
cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time,

and

...
now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary.

It definitely was compiling just fine until 16.3.7, because this was the version that I have been using as my main compiler at work before switching to 16.4.0 two days ago. Our ubiquitously used logging library depends on Boost.Log which suddenly became affected from the workaround in Boost.Proto no longer compiling.

Unfortunately, I've never compiled our production code with any of the 16.4-pre versions. I only did with my C++20 Modules experiments during my talk preparations, but I noticed that despite the seemingly minor bump 16.3 -> 16.4, the compiler learned a couple of new features (e.g. concepts, the new C++20 syntax). So, until there is a thorough exploration with all Boost libs compiled with msvc 16.4.0 in all 4 modes (32/64, debug/release), there might lurk other surprises as well.

Ciao Dani

I'm not sure I can reproduce this. I'm trying to run with four different configs:

based on visual studio build tools 16.3.x toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest based on visual studio build tools 16.4.0 toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest

running in proto ..\..\b2 [config from above] test works fine for all versions....so this bug isn't covered by a test I'm guessing.

Running in log ..\..\b2 [config from above] test

causes the log build to fail for both 16.3 and 16.4 for the configurations that use cxxflags=/std:c++latest. This can be seen in the regression tests for boost.log: https://www.boost.org/development/tests/develop/developer/log.html https://www.boost.org/development/tests/master/developer/log.html

teeks99-07-v16[m|d]-64onAMD64 is the normal msvc-14.2 teeks99-07-v16[m|d]l-64onAMD64 is the msvc-14.2 with cxxflags=/std:c++latest

The error looks something like this (and goes on for a bit)

D:\boost\libs\log>..\..\b2 toolset=msvc-14.2 cxxflags=/std:c++latest test Performing configuration checks

- default address-model : 32-bit (cached) - default architecture : x86 (cached) - symlinks supported : yes (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - has_icu builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - message-compiler : yes (cached) ...patience... ...patience... ...patience... ...patience... ...patience... ...found 23437 targets... ...updating 334 targets... compile-c-c++ ..\..\bin.v2\libs\log\build\msvc-14.2\debug\threadapi-win32\threading-multi\syslog_backend.obj syslog_backend.cpp D:\boost\boost/asio/async_result.hpp(44): error C2062: type 'bool' unexpected D:\boost\boost/asio/async_result.hpp(45): error C2143: syntax error: missing ';' before '{' D:\boost\boost/asio/async_result.hpp(45): error C2447: '{': missing function header (old-style formal list?) D:\boost\boost/asio/async_result.hpp(56): error C7568: argument list missing after assumed function template 'callable_with' D:\boost\boost/asio/async_result.hpp(58): note: see reference to class template instantiation 'boost::asio::detail::is_co

I tried a `D:\boost\libs\proto> git checkout ef2e94fe299449c4b23f305a854de0b5b48248be` and had the exact same results as above.

Can you provide some steps to minimally reproduce this issue?

This is not the compile error that I was running into, it's been the same one as Tobias did. There's probably a small impedance mismatch: you are talking about the unit tests, I was talking about the partial exposure of Boost.Proto through Boost.Log as it is used in our codebase. We are using /std:c++latest /permissive- /Zc:__cplusplus as the only flags that might affect the compiler frontend. In this particular scenario, compilation with msvc up to VS2019 update 3 was fine, but started failing with update 4. I haven't run any of Boost's unit tests for more than a year or so now. Therefore I can't give any additional hints about how the later versions of msvc are faring there, sorry. Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

Tom Kent

6:47 p.m.

On Sun, Dec 8, 2019, 11:35 AM Daniela Engert wrote:

...

Hi Tom!

Am 08.12.2019 um 13:20 schrieb Tom Kent:

On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert wrote:

...
Hi Tom!

Am 06.12.2019 um 22:35 schrieb Tom Kent via Boost:

On Thu, Dec 5, 2019 at 10:15 AM Daniela Engert via Boost wrote:

Am 05.12.2019 um 16:16 schrieb Tobias Loew via Boost:

http://boost.2283326.n4.nabble.com/release-proto-MSVC-19-24-28314-VS-2019-16...

cause it's a showstopper for the latest VS 2019 (16.4.0).

It's not an error introduced in 1.72 but already there for a long time,

and

now the latest MSVC version produces an error on that MSVC-workaround.

I've noticed this as well, today. As a quick hack I simply disabled the workaround at line 233 for BOOST_MSVC >= 1924. Obviously, the problem mentioned by the dead link is no longer a thing. With this modification, Boost.Log is successfully compiling again.

Can you verify that this is only VS 16.4.0 and doesn't apply to 16.3.x? If so, that is scary.

It definitely was compiling just fine until 16.3.7, because this was the version that I have been using as my main compiler at work before switching to 16.4.0 two days ago. Our ubiquitously used logging library depends on Boost.Log which suddenly became affected from the workaround in Boost.Proto no longer compiling.

Unfortunately, I've never compiled our production code with any of the 16.4-pre versions. I only did with my C++20 Modules experiments during my talk preparations, but I noticed that despite the seemingly minor bump 16.3 -> 16.4, the compiler learned a couple of new features (e.g. concepts, the new C++20 syntax). So, until there is a thorough exploration with all Boost libs compiled with msvc 16.4.0 in all 4 modes (32/64, debug/release), there might lurk other surprises as well.

Ciao Dani

I'm not sure I can reproduce this. I'm trying to run with four different configs:

based on visual studio build tools 16.3.x toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest based on visual studio build tools 16.4.0 toolset=msvc-14.2 toolset=msvc-14.2 cxxflags=/std:c++latest

running in proto ..\..\b2 [config from above] test works fine for all versions....so this bug isn't covered by a test I'm guessing.

Running in log ..\..\b2 [config from above] test

causes the log build to fail for both 16.3 and 16.4 for the configurations that use cxxflags=/std:c++latest. This can be seen in the regression tests for boost.log: https://www.boost.org/development/tests/develop/developer/log.html https://www.boost.org/development/tests/master/developer/log.html

teeks99-07-v16[m|d]-64onAMD64 is the normal msvc-14.2 teeks99-07-v16[m|d]l-64onAMD64 is the msvc-14.2 with cxxflags=/std:c++latest

The error looks something like this (and goes on for a bit)

D:\boost\libs\log>..\..\b2 toolset=msvc-14.2 cxxflags=/std:c++latest test Performing configuration checks

- default address-model : 32-bit (cached) - default architecture : x86 (cached) - symlinks supported : yes (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - has_icu builds : no (cached) - BOOST_COMP_GNUC >= 4.3.0 : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - message-compiler : yes (cached) ...patience... ...patience... ...patience... ...patience... ...patience... ...found 23437 targets... ...updating 334 targets... compile-c-c++ ..\..\bin.v2\libs\log\build\msvc-14.2\debug\threadapi-win32\threading-multi\syslog_backend.obj syslog_backend.cpp D:\boost\boost/asio/async_result.hpp(44): error C2062: type 'bool' unexpected D:\boost\boost/asio/async_result.hpp(45): error C2143: syntax error: missing ';' before '{' D:\boost\boost/asio/async_result.hpp(45): error C2447: '{': missing function header (old-style formal list?) D:\boost\boost/asio/async_result.hpp(56): error C7568: argument list missing after assumed function template 'callable_with' D:\boost\boost/asio/async_result.hpp(58): note: see reference to class template instantiation 'boost::asio::detail::is_co

I tried a `D:\boost\libs\proto> git checkout ef2e94fe299449c4b23f305a854de0b5b48248be` and had the exact same results as above.

Can you provide some steps to minimally reproduce this issue?

This is not the compile error that I was running into, it's been the same one as Tobias did. There's probably a small impedance mismatch: you are talking about the unit tests, I was talking about the partial exposure of Boost.Proto through Boost.Log as it is used in our codebase. We are using /std:c++latest /permissive- /Zc:__cplusplus as the only flags that might affect the compiler frontend. In this particular scenario, compilation with msvc up to VS2019 update 3 was fine, but started failing with update 4. I haven't run any of Boost's unit tests for more than a year or so now. Therefore I can't give any additional hints about how the later versions of msvc are faring there, sorry.

Ciao Dani

-- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

So building boost log should reproduce the problem? If not, can you give a few lines that will do it? It sounds like this won't prevent the building of any boost libraries, just user code, right? Tom

...

Vinnie Falco

4:16 p.m.

On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse via Boost wrote:

...

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

Now I'm seeing a warning from Boost.Chrono: compile-c-c++ bin.v2\libs\chrono\build\msvc-14.0\release\address-model-64\cxxstd-14-iso\threading-multi\process_cpu_clocks.obj 814process_cpu_clocks.cpp 815.\boost/detail/winapi/get_last_error.hpp(15): note: This header is deprecated. Use instead. 816.\boost/detail/winapi/get_current_process.hpp(15): note: This header is deprecated. Use instead. 817.\boost/detail/winapi/get_process_times.hpp(15): note: This header is deprecated. Use instead. 818compile-c-c++ bin.v2\libs\chrono\build\msvc-14.0\release\address-model-64\cxxstd-14-iso\threading-multi\thread_clock.obj 819thread_clock.cpp 820.\boost/detail/winapi/get_last_error.hpp(15): note: This header is deprecated. Use instead. 821.\boost/detail/winapi/get_current_thread.hpp(15): note: This header is deprecated. Use instead. 822.\boost/detail/winapi/get_thread_times.hpp(15): note: This header is deprecated. Use instead. Sorry!!

Andrey Semashev

5:20 p.m.

On 2019-12-08 19:16, Vinnie Falco via Boost wrote:

...

On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse via Boost wrote:

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

Now I'm seeing a warning from Boost.Chrono:

compile-c-c++ bin.v2\libs\chrono\build\msvc-14.0\release\address-model-64\cxxstd-14-iso\threading-multi\process_cpu_clocks.obj 814process_cpu_clocks.cpp 815.\boost/detail/winapi/get_last_error.hpp(15): note: This header is deprecated. Use instead. 816.\boost/detail/winapi/get_current_process.hpp(15): note: This header is deprecated. Use instead. 817.\boost/detail/winapi/get_process_times.hpp(15): note: This header is deprecated. Use instead. 818compile-c-c++ bin.v2\libs\chrono\build\msvc-14.0\release\address-model-64\cxxstd-14-iso\threading-multi\thread_clock.obj 819thread_clock.cpp 820.\boost/detail/winapi/get_last_error.hpp(15): note: This header is deprecated. Use instead. 821.\boost/detail/winapi/get_current_thread.hpp(15): note: This header is deprecated. Use instead. 822.\boost/detail/winapi/get_thread_times.hpp(15): note: This header is deprecated. Use instead.

Sorry!!

This is on Boost.WinAPI develop only. I was planning to merge it to master after the release.

Vinnie Falco

5:22 p.m.

On Sun, Dec 8, 2019 at 9:21 AM Andrey Semashev via Boost wrote:

...

This is on Boost.WinAPI develop only. I was planning to merge it to master after the release.

\phew, well that's a relief :) Not a big deal then. Thanks!

1815

Age (days ago)

1832

Last active (days ago)

List overview

Download

31 comments

11 participants

participants (11)

Adam Wulkiewicz
Andrey Semashev
Daniela Engert
Edward Diener
Marshall Clow
Mateusz Loskot
Michael Caisse
Raffi Enficiaud
Tobias Loew
Tom Kent
Vinnie Falco