This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Fix the monetary locale pos/neg_format test for Windows and macOS
ClosedPublic

Authored by mstorsjo on Feb 25 2022, 2:10 AM.

Details

Summary

The zh_CN.UTF-8 locale on Glibc has got n_sign_posn == 4 (which means
having the negative sign just after the currency symbol), but has
int_n_sign_posn == 1 (which means before the string).

On Windows, there's no separate int_n_sign_posn field, so the same
n_sign_posn (which is 4 there too) is used for international currency
formatting too. This makes the ordering for the international case on
Windows be the same as for the national one right above it.

On Apple platforms, the fr_FR.UTF-8 locale has got n_sign_posn == 2
but p_sign_posn == 1, giving a different order for the French locale
for the negative format.

On Apple platforms for the zh_CN.UTF-8 locale, both n_sign_posn and
int_n_sign_posn are 4, but p_sign_posn and int_p_sign_posn are 1.

Diff Detail

Event Timeline

mstorsjo requested review of this revision.Feb 25 2022, 2:10 AM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 25 2022, 2:10 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

I have no particular desire to block this, but should it scope-creep into a full refactor instead? (see my comment inline)

libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
150

Is the order always either value-none-symbol-sign or sign-value-none-symbol?
Thus, could every one of these tests (even the ones you're not touching) profitably be refactored into something like this?

        Fnf f(LOCALE_fr_FR_UTF_8, 1);
        std::money_base::pattern p = f.neg_format();
#ifdef __APPLE__
        assert_has_sign_at_back(p);
#else
        assert_has_sign_at_front(p);
#endif
mstorsjo added inline comments.Feb 25 2022, 8:29 AM
libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
150

I think there’s practically 5 different orders, so it could be possible to do something like that, yes. I’ll see if I can make a sensible improvement with that idea.

mstorsjo updated this revision to Diff 411647.Feb 26 2022, 3:01 PM

Factorized the asserts into functions like assert_sign_symbol_none_value(), which asserts that specific token order; in practice each test had 4 different unique sequences.

This revision is now accepted and ready to land.Feb 27 2022, 9:04 AM