The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
On 10/25/21 22:22, Peter Dimov via Boost wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
It seems to be unavailable in AppVeyor, so I don't think I will be testing it before the beta. And also unlikely before 1.78.
On Mon, Oct 25, 2021 at 2:56 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 10/25/21 22:22, Peter Dimov via Boost wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
It seems to be unavailable in AppVeyor, so I don't think I will be testing it before the beta. And also unlikely before 1.78.
It's available in Azure Pipelines. And B2 already has support for the prerelease version. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
René Ferdinand Rivera Morell wrote:
It's available in Azure Pipelines. And B2 already has support for the prerelease version.
Indeed it does; everything seems to work pretty well. Would be nice if we get support for cxxstd=20 though, as it's currently silently ignored, which leads to confusion. :-) https://github.com/bfgroup/b2/pull/103
Andrey Semashev wrote:
On 10/25/21 22:22, Peter Dimov via Boost wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
It seems to be unavailable in AppVeyor, so I don't think I will be testing it before the beta. And also unlikely before 1.78.
It seems to be available on GHA: https://github.blog/changelog/2021-08-23-github-actions-windows-server-2022-... I ran ` b2 -j32 toolset=msvc-14.3 libs/atomic/test libs/filesystem/test libs/log/test cxxstd=14,17,latest` and the result is msvc.link.dll bin.v2\libs\log\example\event_log\msvc-14.3\debug\cxxstd-14-iso\threadapi-win32\threading-multi\event_log_messages-vc143-mt-gd-x64-1_78.dll msvc.link.dll bin.v2\libs\log\example\event_log\msvc-14.3\debug\cxxstd-17-iso\threadapi-win32\threading-multi\event_log_messages-vc143-mt-gd-x64-1_78.dll msvc.link.dll bin.v2\libs\log\example\event_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\event_log_messages-vc143-mt-gd-x64-1_78.dll compile-c-c++ bin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\sinks_async_ordering.obj sinks_async_ordering.cpp libs\log\example\doc\sinks_async_ordering.cpp(64): error C2672: 'boost::log::v2_mt_nt6::make_attr_ordering': no matching overloaded function found libs\log\example\doc\sinks_async_ordering.cpp(64): error C2893: Failed to specialize function template 'aux::make_attr_ordering_type<FunT,boost::enable_if_c<boost::log::v2_mt_nt6::aux::arity_of<FunT>::value==2,void>::type,aux::first_argument_type_of<FunT>::type,aux::second_argument_type_of<FunT>::type,boost::enable_if_c<boost::is_same<Arg1T,Arg2T>::value,void>::type>::type boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)' with [ Arg1T=aux::first_argument_type_of<FunT>::type, Arg2T=aux::second_argument_type_of<FunT>::type ] C:\boost-git\develop\boost/log/utility/record_ordering.hpp(215): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering' libs\log\example\doc\sinks_async_ordering.cpp(64): note: With the following template arguments: libs\log\example\doc\sinks_async_ordering.cpp(64): note: 'FunT=std::less<unsigned int>' libs\log\example\doc\sinks_async_ordering.cpp(64): error C2783: 'boost::log::v2_mt_nt6::attribute_value_ordering<ValueT,FunT> boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)': could not deduce template argument for 'ValueT' C:\boost-git\develop\boost/log/utility/record_ordering.hpp(186): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering' call "bin.v2\standalone\msvc\msvc-14.3\msvc-setup.bat" >nul cl /Zm800 -nologo "libs\log\example\doc\sinks_async_ordering.cpp" -c -Fo"bin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\sinks_async_ordering.obj" -TP /bigobj /wd4003 /wd4456 /wd4459 /wd4503 /wd4675 /EHs /std:c++latest /GR /Zc:throwingNew /Z7 /Od /Ob0 /W3 /MDd /Zc:forScope /Zc:wchar_t /Zc:inline /favor:blend -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DYN_LINK=1 -DBOOST_LOG_SETUP_DYN_LINK=1 -DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_SSSE3 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_USE_DLL=1 -DBOOST_THREAD_WIN32 -DDATE_TIME_INLINE -DNOMINMAX -DSECURITY_WIN32 -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS "-I." ...failed compile-c-c++ bin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\sinks_async_ordering.obj... ...skipped <pbin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>sinks_async_ordering.exe for lack of <pbin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>sinks_async_ordering.obj... ...skipped <pbin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>sinks_async_ordering.pdb for lack of <pbin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>sinks_async_ordering.obj... compile-c-c++ bin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\main.obj main.cpp libs\log\example\bounded_async_log\main.cpp(91): error C2672: 'boost::log::v2_mt_nt6::make_attr_ordering': no matching overloaded function found libs\log\example\bounded_async_log\main.cpp(91): error C2893: Failed to specialize function template 'aux::make_attr_ordering_type<FunT,boost::enable_if_c<boost::log::v2_mt_nt6::aux::arity_of<FunT>::value==2,void>::type,aux::first_argument_type_of<FunT>::type,aux::second_argument_type_of<FunT>::type,boost::enable_if_c<boost::is_same<Arg1T,Arg2T>::value,void>::type>::type boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)' with [ Arg1T=aux::first_argument_type_of<FunT>::type, Arg2T=aux::second_argument_type_of<FunT>::type ] C:\boost-git\develop\boost/log/utility/record_ordering.hpp(215): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering' libs\log\example\bounded_async_log\main.cpp(91): note: With the following template arguments: libs\log\example\bounded_async_log\main.cpp(91): note: 'FunT=std::less<unsigned int>' libs\log\example\bounded_async_log\main.cpp(91): error C2783: 'boost::log::v2_mt_nt6::attribute_value_ordering<ValueT,FunT> boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)': could not deduce template argument for 'ValueT' C:\boost-git\develop\boost/log/utility/record_ordering.hpp(186): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering' call "bin.v2\standalone\msvc\msvc-14.3\msvc-setup.bat" >nul cl /Zm800 -nologo "libs\log\example\bounded_async_log\main.cpp" -c -Fo"bin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\main.obj" -TP /bigobj /wd4003 /wd4456 /wd4459 /wd4503 /wd4675 /EHs /std:c++latest /GR /Zc:throwingNew /Z7 /Od /Ob0 /W3 /MDd /Zc:forScope /Zc:wchar_t /Zc:inline /favor:blend -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DYN_LINK=1 -DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_SSSE3 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_USE_DLL=1 -DBOOST_THREAD_WIN32 -DDATE_TIME_INLINE -DNOMINMAX -DSECURITY_WIN32 -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS "-I." ...failed compile-c-c++ bin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\main.obj... ...skipped <pbin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>bounded_async_log.exe for lack of <pbin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>main.obj... ...skipped <pbin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>bounded_async_log.pdb for lack of <pbin.v2\libs\log\example\bounded_async_log\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi>main.obj... ...failed updating 2 targets... ...skipped 4 targets...
On 10/26/21 00:20, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
It seems to be unavailable in AppVeyor, so I don't think I will be testing it before the beta. And also unlikely before 1.78.
It seems to be available on GHA:
https://github.blog/changelog/2021-08-23-github-actions-windows-server-2022-...
I don't run Windows builds on GHA, so I'll probably wait until it is available in AppVeyor.
I ran ` b2 -j32 toolset=msvc-14.3 libs/atomic/test libs/filesystem/test libs/log/test cxxstd=14,17,latest` and the result is
compile-c-c++ bin.v2\libs\log\example\doc\msvc-14.3\debug\cxxstd-latest-iso\threadapi-win32\threading-multi\sinks_async_ordering.obj sinks_async_ordering.cpp libs\log\example\doc\sinks_async_ordering.cpp(64): error C2672: 'boost::log::v2_mt_nt6::make_attr_ordering': no matching overloaded function found libs\log\example\doc\sinks_async_ordering.cpp(64): error C2893: Failed to specialize function template 'aux::make_attr_ordering_type<FunT,boost::enable_if_c<boost::log::v2_mt_nt6::aux::arity_of<FunT>::value==2,void>::type,aux::first_argument_type_of<FunT>::type,aux::second_argument_type_of<FunT>::type,boost::enable_if_c<boost::is_same<Arg1T,Arg2T>::value,void>::type>::type boost::log::v2_mt_nt6::make_attr_ordering(const boost::log::v2_mt_nt6::attribute_name &,const FunT &)' with [ Arg1T=aux::first_argument_type_of<FunT>::type, Arg2T=aux::second_argument_type_of<FunT>::type ] C:\boost-git\develop\boost/log/utility/record_ordering.hpp(215): note: see declaration of 'boost::log::v2_mt_nt6::make_attr_ordering' libs\log\example\doc\sinks_async_ordering.cpp(64): note: With the following template arguments: libs\log\example\doc\sinks_async_ordering.cpp(64): note: 'FunT=std::less<unsigned int>'
Thanks. Looks like they removed the nested argument typedefs from the standard function objects. Pity, this forces user's code to be more verbose. Should be fixed by: https://github.com/boostorg/log/commit/e957369c806e9c6c08e5e8e5a6a979fcee9bd...
On Mon, Oct 25, 2021 at 2:22 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
I've got a couple testers running it, results are up in the regression test matrix: https://www.boost.org/development/tests/master/developer/summary.html https://www.boost.org/development/tests/develop/developer/summary.html Would it be worthwhile for us to push back the release a week to de-conflict with this release? I'd like to build beta binaries for it, but it will be tricky to get out if the final version isn't available until monday. Tom
On 26/10/2021 08:22, Peter Dimov wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
This is not the first time that an MSVC release has conflicted with Boost's release schedule -- it seems likely that Microsoft's release date targets were chosen with similar logic to Boost's. Would it make sense to permanently shift the Boost calendar target to reduce the risk of future such conflicts?
On 27/10/2021 03:10, Gavin Lambert via Boost wrote:
On 26/10/2021 08:22, Peter Dimov wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
This is not the first time that an MSVC release has conflicted with Boost's release schedule -- it seems likely that Microsoft's release date targets were chosen with similar logic to Boost's.
Would it make sense to permanently shift the Boost calendar target to reduce the risk of future such conflicts?
A major release of MSVC only happens every few years. Most of the userbase won't touch a new major MSVC release for a year in any case. Me personally, I'm very relaxed about supporting new major MSVC releases immediately, everybody can afford to wait until three months or so following a MSVC major release. Now, it has been in the past that Boost didn't work right on a new major MSVC release for a year afterwards. I remember sending in patches and hassling people to up their game on that. But that was a long time ago now, and back when Boost wasn't as vibrant as it is today. Niall
Am 27.10.2021 um 14:21 schrieb Niall Douglas via Boost:
On 27/10/2021 03:10, Gavin Lambert via Boost wrote:
On 26/10/2021 08:22, Peter Dimov wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
This is not the first time that an MSVC release has conflicted with Boost's release schedule -- it seems likely that Microsoft's release date targets were chosen with similar logic to Boost's.
Would it make sense to permanently shift the Boost calendar target to reduce the risk of future such conflicts?
A major release of MSVC only happens every few years. Most of the userbase won't touch a new major MSVC release for a year in any case. Me personally, I'm very relaxed about supporting new major MSVC releases immediately, everybody can afford to wait until three months or so following a MSVC major release.
Now, it has been in the past that Boost didn't work right on a new major MSVC release for a year afterwards. I remember sending in patches and hassling people to up their game on that. But that was a long time ago now, and back when Boost wasn't as vibrant as it is today.
This might certainly have been true in the past. These days, the difference between latest VS2019 (i.e. msvc 16.11.5) and latest VS2022 (i.e. msvc 17.0) is much smaller with a new compiler being released on a monthly basis or so. The current release candidate is a perfect vehicle for testing what VS2022 is about to bring on the plate. Ciao Dani
On Wed, Oct 27, 2021 at 2:21 PM Niall Douglas via Boost <boost@lists.boost.org> wrote:
A major release of MSVC only happens every few years. Most of the userbase won't touch a new major MSVC release for a year in any case. Me personally, I'm very relaxed about supporting new major MSVC releases immediately, everybody can afford to wait until three months or so following a MSVC major release.
Personally I run preview versions of MSVC and it'd be nice if it 'just worked' with Boost. There's no need to wait until a stable release to work on compatibility either. On the contrary, both Boost and MSVC might benefit from earlier work on 'integration'. That said, I think MSVC is in better shape too then it was during the VC6 era so it might be less of an issue. -- Olaf
On 10/27/21 05:10, Gavin Lambert via Boost wrote:
On 26/10/2021 08:22, Peter Dimov wrote:
The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.
This is not the first time that an MSVC release has conflicted with Boost's release schedule -- it seems likely that Microsoft's release date targets were chosen with similar logic to Boost's.
Would it make sense to permanently shift the Boost calendar target to reduce the risk of future such conflicts?
IMHO, Boost doesn't need to align its schedule to release of any particular compiler. We don't do that for any other compiler anyway.
On Wed, Oct 27, 2021 at 8:29 AM Andrey Semashev wrote:
On 10/27/21 05:10, Gavin Lambert via Boost wrote:
This is not the first time that an MSVC release has conflicted with Boost's release schedule -- it seems likely that Microsoft's release date targets were chosen with similar logic to Boost's.
Would it make sense to permanently shift the Boost calendar target to reduce the risk of future such conflicts?
IMHO, Boost doesn't need to align its schedule to release of any particular compiler. We don't do that for any other compiler anyway.
+1. Also, since Boost 1.67 or so we disabled the Boost.Config outdated diagnostic for unknown new versions of MSVC: https://github.com/boostorg/config/commit/5ad0730630188b55e2ee554dec53b5498f... i.e. No more "Boost.Config is older than your compiler version" messages. And I doubt users are turning on BOOST_ASSERT_CONFIG for the #error. Glen
participants (9)
-
Andrey Semashev -
Daniela Engert -
Gavin Lambert -
Glen Fernandes -
Niall Douglas -
Olaf van der Spek -
Peter Dimov -
René Ferdinand Rivera Morell -
Tom Kent