[libcxx] [test] Skip the get/put long_double_ru_RU tests on Glibc < 2.27

[mstorsjo]

Summary

Those older versions used a different monetary decimal separator.
To avoid unnecessary churn to support that, just skip the test
on those older versions. (Up until recently, the whole test was
XFAILed on all versions of glibc.)

[uabelho]

Thanks! The tests pass for me now with glibc 2.17

[mstorsjo]

In D120979#3359386, @uabelho wrote:

Thanks! The tests pass for me now with glibc 2.17

Great! I'll wait for a libc++ approver still before pushing.

[uabelho]

In D120979#3359388, @mstorsjo wrote:

In D120979#3359386, @uabelho wrote:

Thanks! The tests pass for me now with glibc 2.17

Great! I'll wait for a libc++ approver still before pushing.

SOunds good!

[• Quuxplusone]

libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp

61–69

This smells like the wrong way to do it, but I suppose we don't have an llvm-lit feature flag for this. Ping @ldionne — what do you think is the right approach here?

[mstorsjo]

libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp

61–69

Yeah it's not the ideal fix unfortunately... We don't have a flag with the glibc version at that level. (And if we had, would we need to do e.g. // UNSUPPORTED: glibc-2.11, glibc-2.12, glibc-2.13, glibc-2.14, ...?)

[mstorsjo]

Add a "bug" feature to check for, for the older glibc versions. We don't have the glibc versions as features to check for directly as XFAIL: glibc-2.26 etc (which would require massive expressions for all possibly relevant older versions - the issue manifested on RHEL with glibc 2.17), but we can easily check for the specific behaviour we expect.

[mstorsjo]

Fix the no-localization CI configuration

[uabelho]

I've verified that the current patch solves the problem we see with glibc 2.17

[ldionne]

@uabelho Just out of curiosity, what's the system you're running on that has glibc 2.27?

I would like to put a bound on what systems are supported by our test suite, to avoid unreasonable workarounds. I don't necessarily this one is unreasonable, however it's important to have an explicit support window to keep things under control.

[uabelho]

In D120979#3368343, @ldionne wrote:

@uabelho Just out of curiosity, what's the system you're running on that has glibc 2.27?

It's RHEL 7 (and it's glibc 2.17).

libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.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
 //
 //===----------------------------------------------------------------------===//
 
 // NetBSD does not support LC_MONETARY at the moment
 // XFAIL: netbsd
 
 // REQUIRES: locale.ru_RU.UTF-8
 
+// XFAIL: glibc-old-ru_RU-decimal-point
+
 // <locale>
 
 // class money_get<charT, InputIterator>
 
 // iter_type get(iter_type b, iter_type e, bool intl, ios_base& iob,
 //               ios_base::iostate& err, long double& v) const;
 
 #include <locale>

 
 static std::wstring convert_thousands_sep(std::wstring const& in) {
   return LocaleHelpers::convert_thousands_sep_ru_RU(in);
 }
 #endif // TEST_HAS_NO_WIDE_CHARACTERS
 
 int main(int, char**)
 {
     std::ios ios(0);
     std::string loc_name(LOCALE_ru_RU_UTF_8);
     ios.imbue(std::locale(ios.getloc(),
                           new std::moneypunct_byname<char, false>(loc_name)));
     ios.imbue(std::locale(ios.getloc(),
                           new std::moneypunct_byname<char, true>(loc_name)));
 #ifndef TEST_HAS_NO_WIDE_CHARACTERS
     ios.imbue(std::locale(ios.getloc(),
                           new std::moneypunct_byname<wchar_t, false>(loc_name)));
     ios.imbue(std::locale(ios.getloc(),
                           new std::moneypunct_byname<wchar_t, true>(loc_name)));
 #endif
     std::string symbol(LocaleHelpers::currency_symbol_ru_RU());
     {
         const my_facet f(1);
         // char, national
         {   // zero

libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.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
 //
 //===----------------------------------------------------------------------===//
 
 // NetBSD does not support LC_MONETARY at the moment
 // XFAIL: netbsd
 
 // REQUIRES: locale.ru_RU.UTF-8
 
+// XFAIL: glibc-old-ru_RU-decimal-point
+
 // <locale>
 
 // class money_put<charT, OutputIterator>
 
 // iter_type put(iter_type s, bool intl, ios_base& f, char_type fill,
 //               long double units) const;
 
 #include <locale>

libcxx/utils/libcxx/test/features.py

Feature(name='win32-broken-printf-g-precision',
             #include <string.h>
             int main(int, char**) {
               char buf[100];
               snprintf(buf, sizeof(buf), "%#.*g", 0, 0.0);
               return strcmp(buf, "0.");
             }
           """)),
 
+  # Check for Glibc < 2.27, where the ru_RU.UTF-8 locale had
+  # mon_decimal_point == ".", which our tests don't handle.
+  Feature(name='glibc-old-ru_RU-decimal-point',
+          when=lambda cfg: not '_LIBCPP_HAS_NO_LOCALIZATION' in compilerMacros(cfg) and not programSucceeds(cfg, """
+            #include <locale.h>
+            #include <string.h>
+            int main(int, char**) {
+              setlocale(LC_ALL, "ru_RU.UTF-8");
+              return strcmp(localeconv()->mon_decimal_point, ",");
+            }
+          """)),
+
   # 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.