Implement LWG-2381 Inconsistency in parsing floating point numbers

[frederick-vs-ja]

Fixes #2388. Fixes #1582. Fixes #3375. Fixes #3376. Fixes #3378.

Also works towards

• <locale>: wrong field extraction for hexfloats, or special cases like inf #1259 (which is no longer a bug of MSVC STL after merging this PR) and
• <xlocnum>: We don't match numpunct groups correctly in do_get #1277 (only for FP parsing).

And updates references to working draft in <xlocnum> to WG21-N4944.

The new test file is derived from libc++'s test files, except that "inf"/"nan" cases are skipped. It currently seems non-conforming to handle "inf"/"nan" with do_get.

This PR also (possibly) fixes two six pre-existing bugs:

1. std::hexfloat should have no effect on parsing floating-point numbers.
2. When the input sequence represents an overly large but valid floating-point value, e.g., "1.0e320" for double, infinity (or negative infinity) instead of 0.0 should be given.
3. (Thanks to @strega-nil-ms ) do_get should not consider CHAR_MAX or a non-positive char value in grouping() ends the grouping, since it means that the current group is unlimited, but the next group may still be limited.
4. (Thanks to @statementreply ) "9.999 .... [1000 nines] ...9" should be parsed as 10, not 100.
5. (Thanks to @statementreply ) The _Sticky logic should also be applied to hexadecimal representations.
6. (Thanks to @statementreply ) The carrying logic should be less greedy - but it turns out that carrying can be removed, so this PR removes it.

[strega-nil-ms]

That's what I see -- thanks for fixing these bugs in this (fairly crufty!) code 😸

[StephanTLavavej]

Thanks again for this amazing work which I would not have been able to accomplish! 😻 I pushed minor nitpicky changes, nothing substantial (FYI @strega-nil-ms anyways).

With the addition of the charconv test cases, and the "if it doesn't match, at least it should match strtod/strtof" workaround, I am much more confident that we won't be damaging correctness here. Thanks for making your test changes totally non-intrusive too!

The change is still higher risk than most changes, but I believe we're preserving ABI here, and this is a significant improvement over the status quo. Let's do it.

[StephanTLavavej]

I've had to push an additional commit to restore the dllexport surface.

_Parse_fp_with_locale() needs to be templated, otherwise it'll be dllexported when the whole class is.

_Getffld() and _Getffldx() needed special treatment - their static constexpr char _Src[] arrays were implicitly dllexported, which shows up separately from the functions themselves. Accordingly, we need to restore the arrays even though they're unused, and we need to prevent the compiler eliding them, so I'm storing the address of the first element in a top-level volatile pointer, which is sufficient to keep the array in the DLL. (This does not work without volatile.)

[StephanTLavavej]

@frederick-vs-ja The compiler back-end's internal test suite (specifically spec2k eon) found a bug in this PR:

D:\GitHub\STL\out\x64>type meow.cpp

#include <cstdio>
#include <sstream>
using namespace std;

int main() {
    printf("_MSVC_STL_UPDATE: %d\n", static_cast<int>(_MSVC_STL_UPDATE));
    istringstream iss{"0\n"};
    float flt = 1729.0f;
    iss >> flt;
    if (iss) {
        printf("flt: %.1000g\n", flt);
    } else {
        printf("Parsing failure!\n");
    }
}

Before this PR (VS 2022 17.6 Preview 5):

D:\GitHub\STL\out\x64>cl /EHsc /nologo /W4 /MTd /Od meow.cpp && meow
meow.cpp
_MSVC_STL_UPDATE: 202302
flt: 0

After this PR:

D:\GitHub\STL\out\x64>cl /EHsc /nologo /W4 /MTd /Od meow.cpp && meow
meow.cpp
_MSVC_STL_UPDATE: 202304
Parsing failure!

We definitely need test coverage for this scenario.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thank you for this absolutely massive correctness fix and LWG issue resolution, which the maintainers would not have been able to accomplish! We really appreciate it! 😻 🎉 🚀