Add MSVC-2022 to CI Testing

[mborland]

No description provided.

[NAThompson]

Does the one support modules?

[jzmaddock]

Does the one support modules?

Yes, as does the existing VS2019.

[mborland]

@jzmaddock As the MSVC guru does the failure in test_next make sense to you? Some kind of change to default rounding mode in the new release?

[jzmaddock]

No, but I see it's officially released now so I'm downloading as I speak...

BTW, C++11 testing is redundant for msvc - it only supports C++14/17/20.

[jzmaddock]

I'm pretty much stumped on this, I'm unable to reproduce locally at all (which is to say all tests pass with msvc-14.3, compiler version matches that in the test suite). Can anyone else have a try?

[mborland]

I installed a copy of Visual Studio 2022, and am also unable to reproduce this error locally.

[jzmaddock]

Now that VS2022 is released, lets kick this off again....

[jzmaddock]

Matt the failures here I've just been hit with in multiprecision as well: the meaning of "windows-latest" has just changed, we need to change that to "windows-2019", otherwise everything breaks! :(

[jzmaddock]

Never mind, apparently I can commit direct to this branch via the web-interface, CI updated and we'll see what happens.

[NAThompson]

Never mind, apparently I can commit direct to this branch via the web-interface, CI updated and we'll see what happens.

@jzmaddock : Try gh pr checkout 720 using this; I believe that Matt always clicks the "allow edits from maintainers" button so it's easy to collaborate.

[mbs-c]

I'm pretty much stumped on this, I'm unable to reproduce locally at all (which is to say all tests pass with msvc-14.3, compiler version matches that in the test suite). Can anyone else have a try?

@jzmaddock
We just ran into the very same problem in our own builds, with MSVC 19.29, so the current preprocessor logic to disable the test for newer compilers is insufficient.

According to our tests, the error only occurs when running the test in a Windows docker container, which might explain why you were never able to reproduce it. If anyone has any idea how to debug this further, I'd be happy to help.

[mbs-c]

For the sake of completeness, the docker image I used for testing is based on Server Core LTSC 2022 and the test errors I'm seeing inside the container are the following:

Testing type real_concept with initial value 2.22507e-308
.../test_next.cpp(43): error: in "test_main": check float_distance(float_prior(val), val) == 1 has failed [2 != 1]
.../test_next.cpp(47): error: in "test_main": check float_distance((boost::math::nextafter)(val, lower), val) == 1 has failed [2 != 1]
.../test_next.cpp(58): error: in "test_main": check float_distance(float_advance(val, -4), val) == 4 has failed [2 != 4]
Testing type real_concept with initial value -2.22507e-308
.../test_next.cpp(41): error: in "test_main": check float_distance(float_next(val), val) == -1 has failed [-2 != -1]
.../test_next.cpp(45): error: in "test_main": check float_distance((boost::math::nextafter)(val, upper), val) == -1 has failed [-2 != -1]
.../test_next.cpp(57): error: in "test_main": check float_distance(float_advance(val, 4), val) == -4 has failed [-2 != -4]

Edit: Also, building inside the container and running the test outside the container works, so the test failure must be caused by the runtime environment inside the container.

[mbs-c]

I investigated a bit further and the root cause seems to be that ldexp(long double, int), which is called from float_prior_imp, returns different values. When called from test_next, std::ldexp(1.0L, -1075) returns 4.94066e-324 inside the Windows container and 0 outside.

In both cases, the real_concept test case prints "Denormals are flushed to zero." in the beginning.