-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share unified UTF-8/16 parsing with BigInteger #95402
Share unified UTF-8/16 parsing with BigInteger #95402
Conversation
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.
|
src/libraries/System.Runtime.Numerics/src/System/Number.Polyfill.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Runtime.Numerics/src/System/Number.Polyfill.cs
Outdated
Show resolved
Hide resolved
Test failures look unrelated. No integer/biginteger related. |
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?
|
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.