Uh oh!
There was an error while loading. Please reload this page.
Share unified UTF-8/16 parsing with BigInteger - #95402
Conversation
ghost
commented
Nov 29, 2023
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsFollow up of #85978 . Should really be in same PR. Copied latest CoreLib implementation and polyfill internal interfaces. Originally I tried this with heavy ifdefs and tricks like Wanna check with @stephentoub for whether this design is desired.
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
huoyaoyuan
commented
Nov 30, 2023
Test failures look unrelated. No integer/biginteger related. |
tannergooding
commented
Feb 1, 2024
CC. @vargaz, another LLVM OOM. It's not clear to me which line indicates the failing assembly so I can know what needs to be skipped until the final PR can get merged? |
vargaz
commented
Feb 1, 2024
Those failures are happening on other PRs as well, so i think this is ok to merge. |
Follow up of #85978 . Should really be in same PR.
Copied latest CoreLib implementation and polyfill internal interfaces.
This allows sharing UTF unified parsing and formatting code.
Originally I tried this with heavy ifdefs and tricks like
using TChar = System.Char;. Then I realized that all the internal members can be polyfilled in S.R.Numerics, with very little overhead for UTF-16. This also unblocks UTF-8 adoption for BigInteger.Wanna check with @stephentoub for whether this design is desired.