Re: Has testing on msvc been dropped?

From: Daniela Engert (dani_at_[hidden])
Date: 2023-02-27 15:29:59

Am 27.02.2023 um 14:54 schrieb Andrey Semashev via Boost:
> On 2/27/23 15:55, Daniela Engert wrote:
>> Am 27.02.2023 um 13:24 schrieb Andrey Semashev via Boost:
>>> On 2/27/23 15:16, Glen Fernandes wrote:
>>>> On Mon, Feb 27, 2023 at 6:49 AM Daniela Engert wrote:
>>>>
>>>>      I've noticed that e.g. Boost.Log no longer compiles on msvc 19.35 (i.e.
>>>>      VS2022 update 5). Looking at the test matrix to figure out where the
>>>>      problem might lie, I couldn't find any column with the test results of
>>>>      *any* msvc version, lest the current one. Is there a reason for no
>>>>      longer running the tests with msvc compilers?
>>>>
>>>>
>>>> I don't believe it's intentional.
>>>>
>>>> Tom, do you know why the MSVC runners aren't reporting any results?
>>>>   
>>>> Andrey, Log does use Appveyor for MSVC testing
>>>> too:https://ci.appveyor.com/project/Lastique/log
>>>> <https://ci.appveyor.com/project/Lastique/log>  but there's no 1935 being
>>>> tested there.
>>> Yes, Boost.Log is being tested on AppVeyor, and there is a VS2022 job
>>> (not sure which update, though).
>>>
>>> Is it because of this problem?
>>>
>>> https://github.com/boostorg/parameter/issues/111
>>>
>> It's not. The error in question is
>>
>> phoenix\support\preprocessed\vector_10.hpp(62,1): error C7527: 'A0': a template parameter name cannot be reused within its scope
>> phoenix\support\preprocessed\vector_10.hpp(62,1): error C7527: BOOST_FUSION_ADAPT_TPL_STRUCT_NO_PARTIAL(
>> phoenix\support\preprocessed\vector_10.hpp(62,1): error C7527: ^
>> phoenix\support\preprocessed\vector_10.hpp(66,1): message : see previous definition of 'A0'
>> phoenix\support\preprocessed\vector_10.hpp(66,1): message : )
>> phoenix\support\preprocessed\vector_10.hpp(66,1): message : ^
>>
>> BOOST_FUSION_ADAPT_TPL_STRUCT_NO_PARTIAL expands to
>>
>> namespace boost {
>> namespace fusion {
>> namespace traits {
>> template <typename A0> struct tag_of<boost::phoenix::vector1<A0>> {
>>  Â  typedef struct_tag type;
>> };
>> template <typename A0> struct tag_of<boost::phoenix::vector1<A0> const> {
>>  Â  typedef struct_tag type;
>> };
>> } // namespace traits
>> namespace extension {
>> template <typename A0>
>> struct access::struct_member<boost::phoenix::vector1<A0>, 0> {
>>  Â  typedef A0 attribute_type;
>>  Â  typedef A0 A0;
>>  Â  typedef attribute_type type;
>>  Â  template <typename Seq> struct apply {
>>  Â Â Â  typedef typename add_reference<
>>  Â Â Â Â Â Â Â  typename mpl::eval_if<is_const<Seq>, add_const<attribute_type>,
>>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  mpl::identity<attribute_type>>::type>::type type;
>>  Â Â Â  constexpr static type call(Seq &seq) { return seq.a0; }
>>  Â  };
>> };
>> template <typename A0>
>> struct struct_member_name<boost::phoenix::vector1<A0>, 0> {
>>  Â  typedef char const *type;
>>  Â  constexpr static type call() { return "a0"; }
>> };
>> template <typename A0>
>> struct struct_size<boost::phoenix::vector1<A0>> : mpl::int_<1> {};
>> template <typename A0>
>> struct struct_is_view<boost::phoenix::vector1<A0>> : mpl::false_ {};
>> } // namespace extension
>> } // namespace fusion
>> namespace mpl {
>> template <typename> struct sequence_tag;
>> template <typename A0> struct sequence_tag<boost::phoenix::vector1<A0>> {
>>  Â  typedef fusion::fusion_sequence_tag type;
>> };
>> template <typename A0> struct sequence_tag<boost::phoenix::vector1<A0> const> {
>>  Â  typedef fusion::fusion_sequence_tag type;
>> };
>> } // namespace mpl
>> } // namespace boost
>>
>> The offending code is
>>
>> typedef A0 A0;
>>
>> in
>>
>> template <typename A0>
>> struct access::struct_member<boost::phoenix::vector1<A0>, 0>
>>
>> I've checked this expansion on CE with e.g. gcc and it complains for the
>> same reason. I suspect an obsolete workaround in one of the libs that
>> 'boost/log/sinks.hpp' depends on and has now become hostile and holds
>> Boost.Log ransom.
> The typedef is controlled by this condition:
>
> https://github.com/boostorg/fusion/blob/049303436c6698ac96d8a9d8edb7a727b83cf9b7/include/boost/fusion/adapted/struct/detail/adapt_base.hpp#L146
Wonderful, you nailed it - thanks!

By dropping the workarounds in L146 (and L68) I could successfully 
compile with msvc 19.35, 19.29, 19.16, and 19.00 (i.e. the latest 
versions of VS2022, VS2019, VS2017, and VS2015). I didn't bother to 
check older compilers.

> However, I cannot reproduce your error locally by building Boost.Log or
> Boost.Fusion tests. Can you provide a repro, including the compiler
> command line?

The repro is simple: create an otherwise empty TU with just "#include 
<boost/log/sinks.hpp>" in it and compile. Our build system emits this 
compiler invocation:

C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\bin\HostX64\x64\CL.exe /c /Zi /JMC /nologo /W4 /WX /diagnostics:caret /MP /Od /Ob1 /Oi /D QT_STATIC /D __QT6__ /D _UNICODE /D UNICODE /Zc:preprocessor /Gm- /EHsc /RTC1 /MDd /GS /arch:AVX2 /fp:fast /Zc:wchar_t /Zc:forScope /Zc:inline /Zc:rvalueCast /std:c++latest /permissive- /Fo"x64\Debug\\" /Fd"E:\HWPA\lib64\Debug\libEnvironment.pdb" /external:W4 /Gd /TP /FC /errorReport:prompt /Zc:checkGwOdr /Zc:templateScope /Zc:externConstexpr /Zc:__cplusplus /utf-8 /Zc:throwingNew /Zc:strictStrings /bigobj Log.cpp

Thanks,
 Â  Dani

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