CC: @stephentyrone @belkadan

I suspect that this is just the long-standing issue with float parsing on Windows, not Swift-specific.

We would like to do our own float parsing for this and other reasons (SR-7124), but I believe that this is just an underlying platform bug (which MS may have finally fixed recently?)

I suspect it's not even that: I think our enum uniquing is based on the literal kinds, and we don't bother to turn integer literals into floating-point values during the uniquing.

Actually, it's not quite obvious how we would do this checking, since Double is both IntegerLiteralConvertible and FloatLiteralConvertible. Something like NSNumber would in fact treat these as distinct.

Some other edge cases:

enum E: Double {
  case V = 9223372036854775807.0
  case W = 9223372036854775808.0
}

enum E: Double {
  case V = 9223372036854775807
  case W = 9223372036854775806
}

enum E: NumberAsWritten {
  case V = 9223372036854775807.0
  case W = 9223372036854775807
}

@stephentyrone, it seemed to be going through APSInt so, I would suspect that this is on our side and not the system side? This occurs in [TypeCheckDecl.cpp|

TEST(APFloatTest, convertToInteger) {
{{ llvm::APSInt asInt(127, /isUnsigned=/false);}}
{{ bool isExact = false;}}
{{ // 2^63-1}}
{{ APFloat(APFloat::IEEEdouble(), "9223372036854775807.0")}}
{{ .convertToInteger(asInt, APFloat::rmTowardZero, &isExact);}}
{{ EXPECT_EQ(asInt.toString(10), "9223372036854775807");}}
{{ // 2^64-1}}
{{ APFloat(APFloat::IEEEdouble(), "18446744073709551615.0")}}
{{ .convertToInteger(asInt, APFloat::rmTowardZero, &isExact);}}
{{ EXPECT_EQ(asInt.toString(10), "18446744073709551615");}}
{{}}}

Okay, reduced this to a set of test cases which don't require swift at all. Seems like an issue in APFloat?

Additionally, it seems that the conversion error occurs in the convertToInteger call. The APFloat conversion from the string representation retains the correct value.