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>
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
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
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
On Thu, 21 Nov 2019 at 17:37, Michael Caisse 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/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
On 11/23/19 06:42, Mateusz Loskot via Boost wrote:
On Thu, 21 Nov 2019 at 17:37, Michael Caisse via Boost <boost@lists.boost.org> 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
On Sat, 23 Nov 2019 at 20:10, Michael Caisse via Boost <boost@lists.boost.org> wrote:
On 11/23/19 06:42, Mateusz Loskot via Boost wrote:
On Thu, 21 Nov 2019 at 17:37, Michael Caisse via Boost <boost@lists.boost.org> 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
On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse via Boost <boost@lists.boost.org> 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/9254ec55a3d90019cc3223b018bb38b5c1a49dc4/include/boost/asio/ssl/stream.hpp#L717> 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/529ce8dec4a16b8745fe596875e133dc022db345> 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
On Mon, Nov 25, 2019 at 2:54 PM Vinnie Falco <vinnie.falco@gmail.com> 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
On Mon, Nov 25, 2019 at 2:54 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
Boost.Asio still has a defect here: ...<https://github.com/boostorg/asio/blob/9254ec55a3d90019cc3223b018bb38b5c1a49dc4/include/boost/asio/ssl/stream.hpp#L717>
Still a problem Thanks
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
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?
On Tue, Dec 3, 2019 at 7:48 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Tue, Dec 3, 2019 at 7:43 AM Vinnie Falco <vinnie.falco@gmail.com> 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
On Tue, Dec 3, 2019 at 9:42 AM Vinnie Falco <vinnie.falco@gmail.com> 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
On Wed, Dec 4, 2019 at 12:36 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Tue, Dec 3, 2019 at 9:42 AM Vinnie Falco <vinnie.falco@gmail.com> 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
On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow <mclow.lists@gmail.com> 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
On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow <mclow.lists@gmail.com> 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
On Thu, Dec 5, 2019 at 9:07 AM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Wed, Dec 4, 2019 at 8:47 PM Marshall Clow <mclow.lists@gmail.com> 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
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
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
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
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
On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert <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> 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
On 12/8/2019 7:20 AM, Tom Kent via Boost wrote:
On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert <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> 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?
Hi Tom! Am 08.12.2019 um 13:20 schrieb Tom Kent:
On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert <dani@ngrt.de <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
On Sun, Dec 8, 2019, 11:35 AM Daniela Engert <dani@ngrt.de> wrote:
Hi Tom!
Am 08.12.2019 um 13:20 schrieb Tom Kent:
On Sat, Dec 7, 2019 at 12:51 AM Daniela Engert <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> 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
On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse 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.
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 <boost/winapi/get_last_error.hpp> instead. 816.\boost/detail/winapi/get_current_process.hpp(15): note: This header is deprecated. Use <boost/winapi/get_current_process.hpp> instead. 817.\boost/detail/winapi/get_process_times.hpp(15): note: This header is deprecated. Use <boost/winapi/get_process_times.hpp> 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 <boost/winapi/get_last_error.hpp> instead. 821.\boost/detail/winapi/get_current_thread.hpp(15): note: This header is deprecated. Use <boost/winapi/get_current_thread.hpp> instead. 822.\boost/detail/winapi/get_thread_times.hpp(15): note: This header is deprecated. Use <boost/winapi/get_thread_times.hpp> instead. Sorry!!
On 2019-12-08 19:16, Vinnie Falco via Boost wrote:
On Thu, Nov 21, 2019 at 8:37 AM Michael Caisse 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.
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 <boost/winapi/get_last_error.hpp> instead. 816.\boost/detail/winapi/get_current_process.hpp(15): note: This header is deprecated. Use <boost/winapi/get_current_process.hpp> instead. 817.\boost/detail/winapi/get_process_times.hpp(15): note: This header is deprecated. Use <boost/winapi/get_process_times.hpp> 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 <boost/winapi/get_last_error.hpp> instead. 821.\boost/detail/winapi/get_current_thread.hpp(15): note: This header is deprecated. Use <boost/winapi/get_current_thread.hpp> instead. 822.\boost/detail/winapi/get_thread_times.hpp(15): note: This header is deprecated. Use <boost/winapi/get_thread_times.hpp> instead.
Sorry!!
This is on Boost.WinAPI develop only. I was planning to merge it to master after the release.
participants (11)
-
Adam Wulkiewicz -
Andrey Semashev -
Daniela Engert -
Edward Diener -
Marshall Clow -
Mateusz Loskot -
Michael Caisse -
Raffi Enficiaud -
Tobias Loew -
Tom Kent -
Vinnie Falco