-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Update CoreClr, CoreFx, ProjectNTfs, ProjectNTfsTestILC to preview2-26302-01, preview2-26228-08, beta-26301-00, beta-26301-00, respectively (master) #27640
Conversation
Fixing the failures:
I am seeing this locally, but I don't get why:
Edit: Fixed https://github.com/dotnet/corefx/pull/27640/files#diff-b3d39e42f75b9efe89d21eb385ed61f6R6445 public partial struct ConfiguredValueTaskAwaiter : System.Runtime.CompilerServices.ICriticalNotifyCompletion, System.Runtime.CompilerServices.INotifyCompletion Tested locally and it fixes the ApiCompat error. @stephentoub will resolve this issue. Thanks. |
Regarding OSX CI leg - https://github.com/dotnet/core-eng/issues/2808 |
Couldn't update this pull request: Head commit author 'ahsonkhan' is not 'dotnet-maestro-bot' |
…6302-01, preview2-26228-08, beta-26301-00, beta-26301-00, respectively
This commit does several things: - Exposes the new `ValueTask` extensibility model being added in coreclr. The ValueTask-related files will separately be mirrored over to corefx to enable the netstandard build of System.Threading.Tasks.Extensions. - Adapts all `Stream`-derived types to return `ValueTask` instead of `Task` from `WriteAsync`. - Changes the new `WebSocket` `SendAsync` method to return `ValueTask` instead of `Task`, and updates the `ManagedWebSocket` implementation accordingly. Most `SendAsync`s on `ManagedWebSocket` should now return a `ValueTask` that's either completed synchronously (no allocation) or using a pooled object. It now uses the underlying transport's new `WriteAsync` overload that returns `ValueTask`. - Switches more uses of `ReadAsync` and `WriteAsync` over to the new overloads, including in Process, DeflateStream, BrotliStream, File, HttpClient, SslStream, WebClient, BufferedStream, CryptoStream, - Removed some unnecessary array clearing from various routines using ArrayPool (after the clearing was added we changed our minds and decided clearing was only necessary in very specific circumstances) - Implements a custom `IValueTaskSource` in Socket, such that async receives and sends become allocation-free (ammortized). `NetworkStream` then inherits this functionality, such that its new `ReadAsync` and `WriteAsync` are also allocation-free (in the unbounded channel implementations; we can subsequently add it in for bounded). - Implements a custom `IValueTaskSource` in System.Threading.Channels, such that reading and writing are ammortized allocation-free up to one concurrent reader and writer. - A few random things I noticed as I was going through, e.g. missing ConfigureAwait, some incorrect synchronization in tests, etc. - Adds a ton of new tests, mainly in System.Threading.Tasks.Extensions, System.Threading.Channels, and System.Net.Sockets.
…Array (#16692) * Remove Span.NonGenerics and update leftover AsRoS -> AsSpan changes * Move MemoryExtensions.TryGetString to MemoryMarshal and remove TryGetArray * Move TryGetString to common MemoryMarshal.cs * Remove the `this` keyword, not an extension method Signed-off-by: dotnet-bot-corefx-mirror <dotnet-bot@microsoft.com>
21371d4
to
4021734
Compare
@jkotas, per your suggestion I disabled some uapaot configurations to get things to build cleanly, and they did for me locally (with
and I don't see a Configuration.props file anywhere in the vicinity. Suggestions? |
4021734
to
c039b09
Compare
|
c039b09
to
1b24cba
Compare
This was needed to get through the change of Stream.WriteAsync's return type from Task to ValueTask.
1b24cba
to
18fa454
Compare
CI is green (modulo OSX). Merge? |
Couldn't update this pull request: Head commit author 'Jan Kotas' is not 'dotnet-maestro-bot' |
Couldn't update this pull request: Head commit author 'Jan Kotas' is not 'dotnet-maestro-bot' |
To anyone watching: please hold off on merging this until @jkotas gives the go ahead. |
@jkotas those changes will not impact the packages shipping for 2.1. As a general rule you can check for a pkg folder for the library. You may even consider disabling the UAP package entirely, not sure what might happen with that partial package flowing and what havoc it could reek upstack @joperezr may know. |
Where would be the right place to do that? |
After thinking about it some more, there may be use even for the incomplete package as we flow the difference breaking changes through the system. I will disable it if we find that it is causing havoc - it should not because of the only consumer of it is ProjectN TFS. |
Thanks, @jkotas and @ahsonkhan. |
No description provided.