Also opt in to testing the hexadecimal float formatting for glibc; glibc does matches the current test references there.
Details
- Reviewers
ldionne Mordante • Quuxplusone - Group Reviewers
Restricted Project - Commits
- rGe5f362828a62: [libcxx] [test] Simplify the handling of platform specific NAN formatting in…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Rebased on top of current git main, simplifying the already committed fix doing similar things.
libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp | ||
---|---|---|
10907 | How do you feel about always using strings like pnan_padding25 + pnan_sign + "nan" and not have pnan and PNAN? | |
24413 | Is this change still needed? The test currently passes CI without this change. |
libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp | ||
---|---|---|
10907 | That’d work for me too. | |
24413 | It’s not needed, but this is a test that currently only is executed on apple platforms (because it hadn’t passed on FreeBSD). This test does pass on glibc too, so let’s run it there too, for increased test coverage. |
Removed the pnan/PNAN strings and kept literal "nan" and "NAN".
If preferred, I could split out the change to opt in to the hexadecimal formatting tests into a separate change.
I suggest an alternative approach, but I see no reason to block over that, so might as well accept. Feel free to adopt the IF_GLIBC idea or not, I guess.
libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp | ||
---|---|---|
10891 | This is obscure enough I shouldn't really care, but wouldn't it be easier to understand the test if it was like assert(ex == IF_GLIBC("+nan", "nan")); ~~~ assert(ex == IF_GLIBC("+nan*********************", "nan**********************")); and so on? (The IF_GLIBC macro would just be scoped to this one file.) |
libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp | ||
---|---|---|
10891 | I think I’d prefer to not go with this approach. I’ll add windows into the mix soon (which does the same as glibc here) so the macro naming would be less straightforward then. And going further, there could (theoretically, at least in some other test) be more than two different variations, which is easier if the conditionals are centralized. |
I don't mind that approach, but then I prefer a global macro. There are more localization tests disabled due to glibc giving a different result.
I think I'll go with my original approach for now. Especially in this test, I think that results in less clunky code. And for other tests, given that there's more than two platforms that may want to expect different results, the exact form of handling it can differ a bit between all tests. (FWIW I have a couple more glibc locale fixes in my queue in various state of finished, and a bunch of more windows locale fixes on top of those too.)
This is obscure enough I shouldn't really care, but wouldn't it be easier to understand the test if it was like
and so on? (The IF_GLIBC macro would just be scoped to this one file.)