Decimal parsing ignores significant digits below 1e-49

[gafter]

See CodeGenTests.DecimalLiteral_BreakingChange unit test.

Compile and Run:

using System;
class C
{
    static void Main()
    {
        Console.WriteLine(5.00000000000000000001e-29m); // 5.0e-29m + 1e-49m [Dev11/Roslyn rounds]
        Console.WriteLine(5.0000000000000000000000000000001e-29m); // 5.0e-29m + 1e-60m [Dev11 rounds, Roslyn does not]
    }
}

Expected:
0.0000000000000000000000000001
0.0000000000000000000000000001

Actual:
0.0000000000000000000000000001
0.0000000000000000000000000000

[ported from TFS DevDiv 568494]
@cston @VladimirReshetnikov

[VladimirReshetnikov]

This is indeed a bug. Roslyn uses the function decimal.TryParse from BCL to parse decimal literals. There is a bug in that function (BCL team is aware of it, but AFAIK their current plan is not to fix it for back compat reasons). If we stop using decimal.TryParse and implement correct parsing of decimal literals in Roslyn, it would cause behavior in compile-time and runtime to be different.

[codespare]

That is not probably sufficient by itself to justify implementing IEEE 754-2008 and introducing decimal32, decimal64 and decimal128, but perhaps another small reason to start looking at the successor of decimal? Those can now be found in Intel C++ compiler, gcc, SAP, and progressing on the C and C++ language tracks for instance. Independently of the added 5-6 significant digits of decimal128 and the optimizations possible with the 64 and 32 bit formats, which have some applications, using a standard representation will eventually avoid a lot of cross-platform headaches.

[gafter]

@codespare You're welcome to create a new issue proposing that if you think it is worth our effort.

[codespare]

It undoubtedly would be at some point after 1.0 in my opinion, so I will certainly give a try at starting to document it as it deserves. I also recently came across a related issue, with the BCL project if my memory is correct, proposing to add some of the additional functions defined in IEEE 754-2008 for float and double.

Regarding the issue at hand, I believe it could be tracing back to https://github.com/dotnet/coreclr/blob/master/src/classlibnative/bcltype/decimal.cpp#L350 , although it is more an inference at this stage as I haven't gone through BCL ParseDecimal.
Another outstanding question is where does 5.0000000000000000000000000000001e-29m comes from and why not 5.00000000000000000000000000000001e-29m? I will check what the C# specification says on the subject.

[gafter]

See #372 (comment) ; this is now fixed in the BCL.

[gafter]

Assigning to myself to add a test confirming this is fixed in the BCL that Roslyn runs against.