-
Notifications
You must be signed in to change notification settings - Fork 3.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
[corlib] Default to fast Span<T> #9204
Conversation
This needs a rebase. |
Seems to be missing Buffer:Memmove, also the definition of the non generic version of memmove doesn't seem right:
|
@vargaz correct, not sure if we should do ical or try to adopt quite ugly managed implementation from coreclr |
The build doesn't define BIT64, and some code like Span.Clear () depends on it being the correct value:
|
… non-references types. Implement RuntimeImports.RhZeroMemory ().
The build seems to work now but there are a lot of class lib failures. |
if (length != source.Length) | ||
{ | ||
//ChangeCase(a, source.Length - length, b, destination.Length - length, toUpper); | ||
throw new NotImplementedException (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll need to implement this, I just stubbed it out to get the branch to compile (it calls into System.Globalization.Native.so native code in corefx)
… non-references types. Implement RuntimeImports.RhZeroMemory ().
The 32 bit failures are (mostly) caused by the BIT64 define when compiling corlib, some coreclr code depends on a correct type for nuint:
|
… for fast span to work.
@monojenkins commit apidiff and csproj |
@monojenkins backport 2018-06 |
@marek-safar backporting to 2018-06 failed, the patch results in conflicts:
Please backport manually! |
This reverts commit 262c5f4.
This reverts commit 262c5f4. But it leaves externals alone.
Part of mono/mono#7249 Commit migrated from mono/mono@262c5f4
Part of #7249