[libcxx] [test] Fix the put_double, put_long_double tests for clang-cl

[mstorsjo]

Summary

These tests are hit hard by a bug that is fixed in a newer version
of UCRT. Add a test for the specific bug, and XFAIL the tests if
that bug is present (as it is in CI).

With that bug fixed, there's still one aspect in printf formatting that
differs, that requires ifdeffing out a couple parts of the test (hex
float formatting). Based on reading the C standard for printf formatting,
it seems like this isn't necessarily a proper bug in printf, but just a
case of differing optional behaviour.

(Layering this on top of D119930, to reuse the programSucceeds
function added there.)

[mstorsjo]

This has got its dependencies (D119930) committed now, so the concept of tests for specific bugs should be vetted.

[• Quuxplusone]

libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp

17–18

17880

Any appetite to transplant these two tests into a separate file that could be XFAIL: msvc'ed? You could call it, like, put_double.hex.pass.cpp.

libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp

17–18

libcxx/utils/libcxx/test/features.py

99

I missed out on D119930; this approach seems reasonable to me too. But what would you think of giving all these Windows UCRT bugs a common prefix, something like win32-broken-utf8-wchar-ctype, win32-broken-printf-g-precision, and so on?
I assume msvc-broken-... would have the wrong connotation because this affects both msvc and clang-cl, right? Would win32-broken- have better connotations? msc-ucrt-broken-??

[mstorsjo]

libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp

17880

I guess that sounds doable, I'll give that a shot.

libcxx/utils/libcxx/test/features.py

99

Sure, adding a win32- prefix to the bug feature name sounds good to me. I can make a separate review for changing the existing one.

[mstorsjo]

Add a win32- prefix to the feature name, split the hex float formatting tests to separate files to ease XFAILing those specific bits.

[mstorsjo]

Remove XFAIL: LIBCXX-AIX-FIXME from put_double.pass.cpp which now passes.

[• Quuxplusone]

LGTM! (1500 lines per test function... this code is just a mess. 😛 Thanks for dealing with it.)

[mstorsjo]

In D120022#3346006, @Quuxplusone wrote:

LGTM! (1500 lines per test function... this code is just a mess. 😛 Thanks for dealing with it.)

Thanks! I'll hold off of pushing this one (together with D120469 ) until next week, to give some time if someone objects to the feature naming style (win32-broken-...).

libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_double.pass.cpp

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 // <locale>
 
 // class num_put<charT, OutputIterator>
 
 // iter_type put(iter_type s, ios_base& iob, char_type fill, double v) const;
 
-// FIXME: The printf functions in Microsoft's CRT have a couple quirks in
-// corner cases, failing this test:
-// - With the Microsoft UCRT, printf("%#.*g", 0, 0.0) produces "0.0" while
-//   other C runtimes produce "0.". For other precisions than 0, Microsoft's
-//   consistently produce one digit more than others. In the MinGW test setups,
-//   the code is built with __USE_MINGW_ANSI_STDIO=1, which uses MinGW's own
-//   reimplementation of stdio functions, which doesn't have this issue.
-//   This bug requires excluding everything that runs with showpoint() enabled.
-//   https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
-//   This issue is fixed in newer UCRT versions, since 10.0.19041.0.
+// In MSVC environments, some tested aspects are ifdeffed out, due to these issues:
 // - With the Microsoft UCRT, printf("%a", 0.0) produces "0x0.0000000000000p+0"
 //   while other C runtimes produce just "0x0p+0". This requires omitting all
-//   tests of hex float formatting.
+//   tests of hex float formatting. (test7() and test8() are ifdeffed out.)
 //   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
-// XFAIL: msvc
 
+// XFAIL: broken-printf-g-precision
 // XFAIL: LIBCXX-AIX-FIXME
 
 #include <locale>
 #include <ios>
 #include <cassert>
 #include <streambuf>
 #include <cmath>
 #include "test_macros.h"

                 }
             }
         }
     }
 }
 
 void test7()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
     const my_facet f(1);
     {
         double v = -0.;
         std::ios ios(0);
         std::hexfloat(ios);

             ios.precision(16);
             {
             }
             ios.precision(60);
             {
             }
         }
     }
+#endif
 }
 
 void test8()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
     const my_facet f(1);
     {
         double v = 1234567890.125;
         std::ios ios(0);
         std::hexfloat(ios);

                                 }
                             }
                         }
                     }
                 }
             }
         }
     }
+#endif
 }
 
 int main(int, char**)
 {
     test1();
     test2();
     test3();
     test4();
     test5();
     test6();
     test7();
     test8();
 
   return 0;
 }

libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 // <locale>
 
 // class num_put<charT, OutputIterator>
 
 // iter_type put(iter_type s, ios_base& iob, char_type fill, long double v) const;
 
-// FIXME: The printf functions in Microsoft's CRT have a couple quirks in
-// corner cases, failing this test:
-// - With the Microsoft UCRT, printf("%#.*g", 0, 0.0) produces "0.0" while
-//   other C runtimes produce "0.". For other precisions than 0, Microsoft's
-//   consistently produce one digit more than others. In the MinGW test setups,
-//   the code is built with __USE_MINGW_ANSI_STDIO=1, which uses MinGW's own
-//   reimplementation of stdio functions, which doesn't have this issue.
-//   This bug requires excluding everything that runs with showpoint() enabled.
-//   https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
-//   This issue is fixed in newer UCRT versions, since 10.0.19041.0.
+// In MSVC environments, some tested aspects are ifdeffed out, due to these issues:
 // - With the Microsoft UCRT, printf("%a", 0.0) produces "0x0.0000000000000p+0"
 //   while other C runtimes produce just "0x0p+0". This requires omitting all
-//   tests of hex float formatting.
+//   tests of hex float formatting. (test11() is ifdeffed out.)
 //   https://developercommunity.visualstudio.com/t/Printf-formatting-of-float-as-hex-prints/1660844
-// XFAIL: msvc
 
+// XFAIL: broken-printf-g-precision
 // XFAIL: LIBCXX-AIX-FIXME
 
 #include <locale>
 #include <ios>
 #include <cassert>
 #include <streambuf>
 #include <cmath>
 #include "test_macros.h"

                 }
             }
         }
     }
 }
 
 void test11()
 {
+#ifndef _MSC_VER
     char str[200];
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
     const my_facet f(1);
     {
         long double v = -0.;
         std::ios ios(0);
         std::hexfloat(ios);

             ios.precision(16);
             {
             }
             ios.precision(60);
             {
             }
         }
     }
+#endif
 }
 
 void test12()
 {
     std::locale lc = std::locale::classic();
     std::locale lg(lc, new my_numpunct);
 #if (defined(__APPLE__) || defined(TEST_HAS_GLIBC) || defined(__MINGW32__)) && defined(__x86_64__)
 // This test is failing on FreeBSD, possibly due to different representations
 // of the floating point numbers.
+// This test is failing in MSVC environments, where long double is equal to regular
+// double, and instead of "0x9.32c05a44p+27", this prints "0x1.26580b4880000p+30".
     const my_facet f(1);
     char str[200];
     {
         long double v = 1234567890.125;
         std::ios ios(0);
         std::hexfloat(ios);
         // %a
         {

libcxx/utils/libcxx/test/features.py

Feature(name='broken-utf8-wchar-ctype',
           #include <locale.h>
           #include <ctype.h>
           int main(int, char**) {
             setlocale(LC_ALL, "en_US.UTF-8");
             return towlower(L'\\xDA') != L'\\xFA';
           }
           """)),
 
+  # Check for a Windows UCRT bug (fixed in UCRT/Windows 10.0.19041.0).
+  # https://developercommunity.visualstudio.com/t/printf-formatting-with-g-outputs-too/1660837
+  Feature(name='broken-printf-g-precision',
+          when=lambda cfg: '_WIN32' in compilerMacros(cfg) and not programSucceeds(cfg, """
+          #include <stdio.h>
+          #include <string.h>
+          int main(int, char**) {
+            char buf[100];
+            snprintf(buf, sizeof(buf), "%#.*g", 0, 0.0);
+            return strcmp(buf, "0.");
+          }
+          """)),
+
   # Whether Bash can run on the executor.
   # This is not always the case, for example when running on embedded systems.
   #
   # For the corner case of bash existing, but it being missing in the path
   # set in %{exec} as "--env PATH=one-single-dir", the executor does find
   # and executes bash, but bash then can't find any other common shell
   # utilities. Test executing "bash -c 'bash --version'" to see if bash
   # manages to find binaries to execute.