[WIP] Moving the UTF8 Parser/Formatter code into System.Private.CoreLib

[tannergooding]

Today, the UTF8 Parser/Formatter code lives in System.Memory. However, this presents a potential problem with sharing bits of code (namely the Decimal/Double/Single formatters/parsers).

I talked with @GrabYourPitchforks a few times about this and suggested we move the code into System.Private.CoreLib. This allows us to readily share the more complicated code and keep the code in sync between the two.

• We now have a single NumberBuffer instance that carries a Span<byte>
  • The Span<char> buffer previously used by the UTF16 Parser never contained digits outside 0-9 and null anyways.
• I tried to do the minimal number of changes, outside moving to share the NumberToDecimal, NumberToDouble, and NumberToSingle code where possible
  • There are several other places (some tracked by comments) of where we could share more code between the UTF8/UTF16 parser and formatter

[tannergooding]

CC. @danmosemsft, @GrabYourPitchforks, @jkotas, @stephentoub

I'd appreciate some input on this, and if it is a direction we would like to persue. If not, it might be good if we could come up with an alternative for sharing the code (where possible).

[jkotas]

Sounds good to me.

[tannergooding]

Hmmm. Utf8Formatter.TryFormat(bool, Span<byte>, out int, StandardFormat) is currently failing in crossgen (in EvalFuncForConstantArgs) when dealing with FalsValueLowercase.

• I am going to speculate that this is for the ReverseEndianness call in WriteUInt32BigEndian, but I am still trying to confirm. CC. @GrabYourPitchforks

[stephentoub]

@tannergooding, does this help/hurt the throughput of operations like uint.TryParse and uint.TryFormat?

[tannergooding]

does this help/hurt the throughput of operations like uint.TryParse and uint.TryFormat

Still need to check, but I wouldn't expect it to. We were already only dealing with ASCII characters (once we got it into a NumberBuffer) and most of the parsing code was already casting back and forth from int to char (for the various arithmetic operations).

[stephentoub]

Purely a logistical comment, but should we instead do this by moving the code in corefx to shared, letting it mirror over, and then updating the rest of coreclr with the necessary changes? I think that would make the history easier to follow.

[tannergooding]

That sounds like a good idea.

[tannergooding]

Closing this and breaking it into multiple PRs:

• First will be on CoreCLR and will move NumberBuffer to carry Span<byte>.
• Second will be on CoreFX moving the Utf8Parser and Utf8Formatter to shared
• Third will be on CoreCLR pulling the Utf8Parser and Utf8Formatter into S.P.Corelib
  • This includes minimally fixing it to share the newer floating-point parsing code
• Final will be on CoreFX removing the Utf8Parser and Utf8Formatter from System.Memory and type-forwarding it to Corelib

[GrabYourPitchforks]

I'm also looking into the JIT assert.

[AndyAyersMS]

We generally won't prejit methods that rely on HW intrinsics.