Implement async using statement by jcouv · Pull Request #23961 · dotnet/roslyn

jcouv · 2017-12-29T00:27:58Z

The approach here is to re-use all the binding and lowering logic for using, but extend it to support using await. The BoundUsingStatement gets a new field to hold an optional BoundAwaitExpression which will be used during lowering to do await <expr>.DisposeAsync() instead of <expr>Dispose().
All the elements of the bound tree that relate to the IDisposable interface become overloaded to deal with IDisposableAsync in the async scenario.
I've done a little bit of IDE testing, which prompted me to fix some control flow analysis.

jcouv · 2018-01-05T19:27:04Z

@dotnet/roslyn-compiler for review. Thanks #Resolved

jcouv · 2018-01-08T17:39:57Z

@dotnet/roslyn-compiler for review. Thanks #Resolved

cston · 2018-01-09T20:25:30Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

+            BoundMultipleLocalDeclarations declarationsOpt = null;
+            BoundExpression expressionOpt = null;
+            BoundAwaitExpression boundAwaitOpt = null;
+            if (!hasErrors)


Is it necessary to skip binding the expression if IAsyncDisposable has use-site errors? #Resolved

cston · 2018-01-09T20:39:21Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

+                    {
+                        var syntaxForAwait = (SyntaxNode)expressionSyntax ?? declarationSyntax;
+                        BoundExpression placeholder = new BoundAwaitableValuePlaceholder(syntaxForAwait, taskType);
+                        boundAwaitOpt = BindAwait(placeholder, syntaxForAwait, diagnostics).MakeCompilerGenerated();


We're marking the BoundAwaitExpression as compiler generated here, but not in existing await scenarios. Why the difference? #Resolved

We're marking the BoundAwaitExpression as compiler generated here, but not in existing await scenarios. Why the difference?

I guess because there is no corresponding AwaitExpressionSyntax.

In reply to: 160518475 [](ancestors = 160518475)

Because in a case of Using, the await expression is not isomorphic to any expression in the syntax.
We are using a bound node just as a storage for method/property symbols found in binding. The node has no other structure or nesting (like in deconstruct).
I think AwaitableInfo, which is not a bound node, would make things simpler. #Resolved

The main reason why I marked it as compiler-generated is that AsyncMethodToStateMachineRewriter.VisitAwaitExpression expects that a BoundAwaitExpression is attached to some await syntax.
For async-using, we have no await syntax, so I modified the assertion as shown below.

Also, I think it makes sense into terms of bound tree having the same shape as the syntax tree.

private BoundBlock VisitAwaitExpression(BoundAwaitExpression node, BoundExpression resultPlace) { ... Debug.Assert(node.Syntax.IsKind(SyntaxKind.AwaitExpression) || node.WasCompilerGenerated);

In reply to: 160567590 [](ancestors = 160567590)

cston · 2018-01-09T20:42:14Z

src/Compilers/CSharp/Portable/BoundTree/BoundNodes.xml


+  <!--
+  This node is used to represent an awaitable expression of a certain type, when binding an using-await statement.
+  It will be replaced by an actual bound node during lowering.


Minor point: an async using or a using-await. #Resolved

cston · 2018-01-09T22:48:07Z

src/Compilers/CSharp/Portable/FlowAnalysis/PreciseAbstractFlowPass.cs

@@ -311,7 +312,7 @@ protected override bool ConvertInsufficientExecutionStackExceptionToCancelledByS

        /// <summary>
        /// A pending branch.  There are created for a return, break, continue, goto statement,


These are ...? #Resolved

cston · 2018-01-09T22:51:39Z

src/Compilers/CSharp/Portable/FlowAnalysis/PreciseAbstractFlowPass.cs

        /// <summary>
        /// A pending branch.  There are created for a return, break, continue, goto statement,
-        /// yield return, yield break, await expression, and if PreciseAbstractFlowPass.trackExceptions
+        /// yield return, yield break, await expression, foreach/using await, and if PreciseAbstractFlowPass.trackExceptions


Are there pending branches for foreach? #Resolved

Not yet, but that will be coming shortly with foreach-await. I updated the comment pro-actively, as I feared I'd forget to update it in the foreach-await PR. I can replace with PROTOTYPE if you prefer.

In reply to: 160547396 [](ancestors = 160547396)

cston · 2018-01-09T23:01:51Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+using Xunit;
+
+namespace Microsoft.CodeAnalysis.CSharp.UnitTests.CodeGen
+{


Are there tests for using and using await for types that implement IDisposable and IAsyncDisposable? #Resolved

Consider testing using await (null) { }, using await (MethodName) { }. #Resolved

AlekseyTs · 2018-01-10T00:22:08Z

src/Compilers/CSharp/Portable/Errors/MessageID.cs

        IDS_FeatureAttributesOnBackingFields = MessageBase + 12731,

-        IDS_FeatureAsyncStreams = MessageBase + 12777, // PROTOTYPE(async-streams)
+        IDS_FeatureAsyncStreams = MessageBase + 12777, // PROTOTYPE(async-streams) Compat IDs


Compat [](start = 83, length = 6)

Did you mean "Compact"? #Closed

AlekseyTs · 2018-01-10T00:27:42Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

+            if (hasAwait)
+            {
+                iDisposable = this.Compilation.GetWellKnownType(WellKnownType.System_IAsyncDisposable);
+                hasErrors |= ReportUseSiteDiagnostics(iDisposable, diagnostics, _syntax.AwaitKeyword.GetLocation());


hasErrors |= ReportUseSiteDiagnostics(iDisposable, diagnostics, _syntax.AwaitKeyword.GetLocation()); [](start = 16, length = 100)

Is there a reason to differ from regular IDisposable in regard to reporting use-site diagnostics? #Closed

The comment made me think it was unnecessary. But it looks like there was a bug for IDisposable case.

In reply to: 160562446 [](ancestors = 160562446)

AlekseyTs · 2018-01-10T00:31:39Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

+            BoundMultipleLocalDeclarations declarationsOpt = null;
+            BoundExpression expressionOpt = null;
+            BoundAwaitExpression boundAwaitOpt = null;
+            if (!hasErrors)


if (!hasErrors) [](start = 12, length = 15)

We should keep binding expression/declarations, if not for error reporting, then for SemanticModel/IOperation benefits. #Closed

AlekseyTs · 2018-01-10T00:38:55Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

-                        hasErrors = true;
+                if (!hasErrors && hasAwait)
+                {
+                    TypeSymbol taskType = this.Compilation.GetWellKnownType(WellKnownType.System_Threading_Tasks_Task);


GetWellKnownType [](start = 59, length = 16)

I think Binder has a helper that gets the type and reports use-site diagnostics. #Closed

They don't accept a SyntaxToken or a Location. I don't want to multiple overloads, so I just added one to ReportUseSiteDiagnostics.

In reply to: 160563783 [](ancestors = 160563783)

AlekseyTs · 2018-01-10T00:40:15Z

src/Compilers/CSharp/Portable/Binder/UsingStatementBinder.cs

+                    if (!hasErrors)
+                    {
+                        var syntaxForAwait = (SyntaxNode)expressionSyntax ?? declarationSyntax;
+                        BoundExpression placeholder = new BoundAwaitableValuePlaceholder(syntaxForAwait, taskType);


BoundAwaitableValuePlaceholder [](start = 58, length = 30)

MakeCompilerGenerated()? #Closed

VSadov · 2018-01-10T00:50:37Z

src/Compilers/CSharp/Portable/BoundTree/BoundNodes.xml

    <Field Name="IDisposableConversion" Type="Conversion" />
    <Field Name="Body" Type="BoundStatement"/>
+    <!-- A bound await, but with a placeholder instead of an awaited expression -->
+    <Field Name="AwaitOpt" Type="BoundAwaitExpression" Null="allow"/>


I wonder if it is better to factor out {getAwaiter, isCompleted, getResult} as an AwaitableInfo and use it in both BoundAwait and in BoundUsing?
GetAwaitableExpressionInfo is basically returning such info (although via bunch of out params).

Such approach might scale better at representing implicit awaitability than carrying around await nodes on a side. #Resolved

I'm taking a look at this and will get back to you.

In reply to: 160565220 [](ancestors = 160565220)

Pushed a commit that refactors BoundAwaitExpression and extracts an AwaitableInfo.

In reply to: 161033778 [](ancestors = 161033778,160565220)

cston · 2018-01-10T05:28:38Z

src/Compilers/CSharp/Portable/Lowering/LocalRewriter/LocalRewriter_UsingStatement.cs

        /// <summary>
-        /// Lower "using (ResourceType resource = expression) statement" to a try-finally block.
+        /// Lower "using (ResourceType resource = expression) statement" and
+        /// "using await (ResourceType resuorce = expression) statement" to a try-finally block.


Typo: resource #Resolved

Perhaps short the comment to Lower "using [await] (ResourceType resource = expression) statement" to a try-finally block. Similar comment for previous method. #Resolved

cston · 2018-01-10T05:42:50Z

src/Compilers/CSharp/Portable/Lowering/LocalRewriter/LocalRewriter_UsingStatement.cs

+                // local.Dispose()
                disposeCall = BoundCall.Synthesized(syntax, disposedExpression, disposeMethodSymbol);
            }
+            else if (awaitOpt != null && TryGetWellKnownTypeMember(syntax, WellKnownMember.System_IAsyncDisposable__DisposeAsync, out MethodSymbol disposeAsyncMethodSymbol))


If we're reporting use-site diagnostics here, could we skip reporting the use-site diagnostic for IAsyncDisposable in binding? #Resolved

The checks here don't handle missing IDisposable, only missing IDisposable.Dipose().
I agree with you that it's weird to split the use-site diagnostics between here and initial binding. I'll look into this more.

In reply to: 160593496 [](ancestors = 160593496)

Doesn't TryGetWellKnownTypeMember report a diagnostic if the type is missing? #Resolved

If I remove the reporting of use-site diagnostics in binding (for missing IDisposable), then execution does not reach lowering, even when I ask for emit diagnostics.
I think that's because there are errors reported from binding anyways. Namely:

// (6,16): error CS1674: 'C': type used in a using statement must be implicitly convertible to 'System.IDisposable' // using (new C()) Diagnostic(ErrorCode.ERR_NoConvToIDisp, "new C()").WithArguments("C").WithLocation(6, 16), // (9,16): error CS1674: 'C': type used in a using statement must be implicitly convertible to 'System.IDisposable' // using (var x = new C()) Diagnostic(ErrorCode.ERR_NoConvToIDisp, "var x = new C()").WithArguments("C").WithLocation(9, 16)

In reply to: 160863521 [](ancestors = 160863521)

I believe all error reporting for missing members and such should be done in binding. IIRC, the local rewriter can assume that these exist here. Example in: https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Lowering/LocalRewriter/LocalRewriter_StackAlloc.cs when getting the span type

In reply to: 161024454 [](ancestors = 161024454,160863521)

Initial binding doesn't currently check for existing of IDisposable.Dispose().
There are other examples of well-known types and members which are only checked during rewriting, such as AsyncRewriter.VerifyPresenceOfRequiredAPIs().

I don't see anything wrong with that, especially since getting in a situation where IDisposable.Dispose() is missing, but IDisposable exists wouldn't seem common. The same applies to async counterpart APIs. #Resolved

cston · 2018-01-10T06:13:25Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+        {
+            System.Console.Write(""body "");
+            return;
+        }


Consider testing S? s = null; using await (s) { ... }. #Resolved

Thanks for the test suggestions (good ideas). Added them

In reply to: 160596740 [](ancestors = 160596740)

jcouv · 2018-01-19T17:49:17Z

@AlekseyTs @cston Any other feedback? Thanks #Resolved

AlekseyTs · 2018-01-19T18:10:36Z

src/Compilers/CSharp/Portable/Binder/AwaitableInfo.cs

+
+        internal AwaitableInfo Update(MethodSymbol newGetAwaiter, PropertySymbol newIsCompleted, MethodSymbol newGetResult)
+        {
+            if (ReferenceEquals(GetAwaiter, newGetAwaiter) && ReferenceEquals(IsCompleted, newIsCompleted) && ReferenceEquals(GetResult, newGetResult))


ReferenceEquals [](start = 16, length = 15)

ReferenceEquals is fine, but we usually use cast to object and regular == operator to compare references #Closed

Leaving as-is if that's ok.

In reply to: 162693080 [](ancestors = 162693080)

AlekseyTs · 2018-01-19T18:19:51Z

src/Compilers/CSharp/Portable/FlowAnalysis/PreciseAbstractFlowPass.cs

            return null;
        }

+        public abstract bool AsyncUsingAddsPendingBranch { get; }


AsyncUsingAddsPendingBranch [](start = 29, length = 27)

I am not sure why do we need this for using, but regular await expressions don't use similar mechanism. #Closed

The reason is that ControlFlowPass doesn't dig into expressions, so it doesn't add pending branches for awaits (implemented in base class).
I want to get the same behavior for async-using, but without cloning the implementation of VisitUsingStatement.

// from ControlFlowPass public override BoundNode Visit(BoundNode node) { // there is no need to scan the contents of an expression, as expressions // do not contribute to reachability analysis (except for constants, which // are handled by the caller). if (!(node is BoundExpression)) { return base.Visit(node); } return null; }

// from PreciseAbstractFlowPass<LocalState> public override BoundNode VisitAwaitExpression(BoundAwaitExpression node) { VisitRvalue(node.Expression); _pendingBranches.Add(new PendingBranch(node, this.State)); if (_trackExceptions) NotePossibleException(node); return null; } ``` #Resolved

AlekseyTs · 2018-01-19T18:27:06Z

src/Compilers/CSharp/Portable/Lowering/LocalRewriter/LocalRewriter.cs

                }
-
+#if DEBUG
+                LocalRewritingValidator.Validate(loweredStatement);


LocalRewritingValidator.Validate(loweredStatement); [](start = 16, length = 51)

I am concerned that this introduces a new source of stack overflow exception and only for debug. Some test will be testing different code path debug vs. release. Perhaps we should catch and swallow the internal stack overflow exception thrown by this validator. #Closed

Added try/catch inside that method

In reply to: 162696640 [](ancestors = 162696640)

AlekseyTs · 2018-01-19T18:37:46Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+            comp.VerifyDiagnostics(
+                // (6,22): error CS4033: The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task'.
+                //         using await (var x = new C())
+                Diagnostic(ErrorCode.ERR_BadAwaitWithoutVoidAsyncMethod, "var x = new C()").WithLocation(6, 22)


var x = new C() [](start = 74, length = 15)

I think it would be better if the location for the error was the await keyword. It would point precisely to the problem and the part between parenthesis could be quite long, event could span multiple lines. #Closed

AlekseyTs · 2018-01-19T18:57:11Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+";
+            var comp = CreateCompilationWithMscorlib46(source + s_interfaces, options: TestOptions.DebugExe);
+            comp.VerifyDiagnostics();
+            CompileAndVerify(comp, expectedOutput: "C body DisposeAsync");


"C body DisposeAsync" [](start = 51, length = 21)

It would be good to test that the task is actually awaited, which I believe this test doesn't confirm. #Closed

AlekseyTs · 2018-01-19T18:58:11Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+            comp.VerifyDiagnostics(
+                // (8,26): error CS4004: Cannot await in an unsafe context
+                //             using await (var x = new C())
+                Diagnostic(ErrorCode.ERR_AwaitInUnsafeContext, "var x = new C()").WithLocation(8, 26)


var x = new C() [](start = 64, length = 15)

Same comment for location #Closed

AlekseyTs · 2018-01-19T18:58:46Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+            comp.VerifyDiagnostics(
+                // (8,26): error CS1996: Cannot await in the body of a lock statement
+                //             using await (var x = new C())
+                Diagnostic(ErrorCode.ERR_BadAwaitInLock, "var x = new C()").WithLocation(8, 26)


var x = new C() [](start = 58, length = 15)

Same comment for location #Closed

AlekseyTs · 2018-01-19T19:02:12Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+    {
+        System.Action a = () =>
+        {
+            System.Action b = async () => { await local(); }; // this await doesn't count towards Main method


await local() [](start = 44, length = 13)

Shouldn't we be testing using await here? #Closed

AlekseyTs · 2018-01-19T19:02:20Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+
+        async System.Threading.Tasks.Task local()
+        {
+            await local(); // neither does this one


await local(); [](start = 12, length = 14)

Shouldn't we be testing using await here? #Closed

AlekseyTs · 2018-01-19T19:03:28Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+    {
+        System.Action lambda1 = async () =>
+        {
+            System.Action b = async () => { await local(); }; // this await doesn't count towards lambda


await local() [](start = 44, length = 13)

Shouldn't we be testing using await here? #Closed

AlekseyTs · 2018-01-19T19:03:36Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+            System.Action b = async () => { await local(); }; // this await doesn't count towards lambda
+        };
+
+        System.Action lambda2 = async () => await local2(); // this await counts towards lambda


await local2() [](start = 44, length = 14)

Shouldn't we be testing using await here? #Closed

We can't here. The purpose for this lambda is to have an expression body, but async using is a statement.

In reply to: 162705223 [](ancestors = 162705223)

AlekseyTs · 2018-01-19T19:03:47Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+
+            async System.Threading.Tasks.Task innerLocal()
+            {
+                await local(); // this await doesn't count towards local function


await local() [](start = 16, length = 13)

Shouldn't we be testing using await here? #Closed

AlekseyTs · 2018-01-19T19:07:40Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+        finally
+        {
+            System.Console.Write(""before "");
+            await System.Threading.Tasks.Task.CompletedTask;


await System.Threading.Tasks.Task.CompletedTask [](start = 12, length = 47)

Does completed task actually suspend execution? #Closed

AlekseyTs · 2018-01-19T19:11:53Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+            comp.VerifyEmitDiagnostics(
+                // (13,9): error CS0656: Missing compiler required member 'System.IAsyncDisposable.DisposeAsync'
+                //         using await (new C()) { }
+                Diagnostic(ErrorCode.ERR_MissingPredefinedMember, "using await (new C()) { }").WithArguments("System.IAsyncDisposable", "DisposeAsync").WithLocation(13, 9),


using await (new C()) { } [](start = 67, length = 25)

It feels like we should narrow location of this error. #Closed

No response for this comment.

In reply to: 162707185 [](ancestors = 162707185)

AlekseyTs · 2018-01-19T19:20:40Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+        }
+
+        [Fact]
+        public void TestWithMultipleResources()


TestWithMultipleResources [](start = 20, length = 25)

Is this a dupe of TestWithMultipleDeclarations? #Closed

Close enough. I'll remove TestWithMultipleDeclarations which doesn't check order of evaluation of resources.
Thanks

In reply to: 162709276 [](ancestors = 162709276)

AlekseyTs · 2018-01-19T19:22:21Z

Done with review pass (iteration 11) #Closed

cston · 2018-01-20T00:09:11Z

src/Compilers/CSharp/Portable/Lowering/MethodToClassRewriter.cs

+            AwaitableInfo info = node.AwaitableInfo;
+            return node.Update(
+                expression,
+                node.AwaitableInfo.Update(VisitMethodSymbol(info.GetAwaiter), VisitPropertySymbol(info.IsCompleted), VisitMethodSymbol(info.GetResult)),


info.Update(...) #Resolved

cston · 2018-01-20T00:23:33Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+                // (11,9): error CS0165: Use of unassigned local variable 'z'
+                //         z++;
+                Diagnostic(ErrorCode.ERR_UseDefViolation, "z").WithArguments("z").WithLocation(11, 9)
+                );


Do we report an error for await L1(); ...; y++;?
#Resolved

See #24267 for that scenario (reports same errors) and another related one

In reply to: 162762997 [](ancestors = 162762997)

cston · 2018-01-20T00:25:27Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+";
+            var comp = CreateCompilationWithMscorlib46(source + s_interfaces, options: TestOptions.DebugExe);
+            comp.VerifyDiagnostics();
+            var verifier = CompileAndVerify(comp, expectedOutput: "ctor1 ctor2 body dispose2 dispose1 caught");


Are we disposing of s1 if an exception is thrown in new S(2)? #Resolved

AlekseyTs · 2018-01-20T01:04:41Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenAsyncDisposableTests.cs

+    public Task DisposeAsync()
+    {
+        System.Console.Write(""DisposeAsync "");
+        return Task.Delay(10);


return Task.Delay(10); [](start = 8, length = 22)

How do we know that this task is awaited after this method is called? #Closed

Here and in all other similar tests we should await for something inside DisposeAsync and then print something after that. This will confirm that we aren't just calling the method, but also awaiting the task that we are getting from it.

In reply to: 162766376 [](ancestors = 162766376)

Thanks for the clarification. #Resolved

AlekseyTs · 2018-01-20T01:14:31Z

Done with review pass (iteration 12) #Closed

jcouv · 2018-01-22T23:25:57Z

@AlekseyTs Could you take another look when you get the chance? Thanks

Btw, I added a work item to umbrella issue (#24037) to deal with IOperation too.

AlekseyTs

LGTM (iteration 13)

jcouv · 2018-01-23T20:30:01Z

Awesome. Thanks!

jcouv added the Area-Compilers label Dec 29, 2017

jcouv added this to the 16.0 milestone Dec 29, 2017

jcouv self-assigned this Dec 29, 2017

jcouv changed the title ~~Implement async using statement binding and lowering~~ Implement async using statement Dec 29, 2017

jcouv added the Feature - Async Streams Async Streams label Dec 29, 2017

jcouv force-pushed the async-streams2 branch from 39b405c to 82eefc4 Compare December 29, 2017 00:36

jcouv mentioned this pull request Jan 4, 2018

[Umbrella] Work items and test plan for async streams #24037

Closed

Implement async using statement binding and lowering

76aa224

jcouv force-pushed the async-streams2 branch from 82eefc4 to 76aa224 Compare January 5, 2018 19:26

cston reviewed Jan 9, 2018

View reviewed changes

AlekseyTs reviewed Jan 10, 2018

View reviewed changes

VSadov reviewed Jan 10, 2018

View reviewed changes

cston reviewed Jan 10, 2018

View reviewed changes

jcouv requested a review from a team as a code owner January 11, 2018 00:27

Address PR feedback from Chuck and Aleksey

64e59cd

jcouv force-pushed the async-streams2 branch from 7cadb6d to 64e59cd Compare January 11, 2018 05:14

jcouv requested a review from OmarTawfik January 11, 2018 05:22

AlekseyTs reviewed Jan 19, 2018

View reviewed changes

cston reviewed Jan 20, 2018

View reviewed changes

cston approved these changes Jan 20, 2018

View reviewed changes

Address PR feedback from Aleksey

63e5737

AlekseyTs reviewed Jan 20, 2018

View reviewed changes

Fix diagnostic location. Print after Delay. Add test

c96ffda

AlekseyTs approved these changes Jan 23, 2018

View reviewed changes

jcouv merged commit 8bc67d6 into dotnet:features/async-streams Jan 23, 2018

jcouv deleted the async-streams2 branch January 23, 2018 20:30

		@@ -311,7 +312,7 @@ protected override bool ConvertInsufficientExecutionStackExceptionToCancelledByS

		/// <summary>
		/// A pending branch. There are created for a return, break, continue, goto statement,

Conversation

jcouv commented Dec 29, 2017

Uh oh!

jcouv commented Jan 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcouv commented Jan 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Jan 10, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 9, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 10, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Jan 10, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cston Jan 10, 2018 • edited by jcouv Loading Uh oh! There was an error while loading. Please reload this page.

jcouv commented Jan 5, 2018 •

edited

Loading

jcouv commented Jan 8, 2018 •

edited

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

VSadov Jan 10, 2018 •

edited by jcouv

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

cston Jan 9, 2018 •

edited by jcouv

Loading

cston Jan 10, 2018 •

edited by jcouv

Loading

AlekseyTs Jan 10, 2018 •

edited

Loading

AlekseyTs Jan 10, 2018 •

edited

Loading

AlekseyTs Jan 10, 2018 •

edited

Loading

AlekseyTs Jan 10, 2018 •

edited

Loading

AlekseyTs Jan 10, 2018 •

edited

Loading

VSadov Jan 10, 2018 •

edited by jcouv

Loading

cston Jan 10, 2018 •

edited by jcouv

Loading

cston Jan 10, 2018 •

edited by jcouv

Loading

cston Jan 10, 2018 •

edited by jcouv

Loading

cston Jan 11, 2018 •

edited by jcouv

Loading

jcouv Jan 13, 2018 •

edited

Loading

cston Jan 10, 2018 •

edited by jcouv

Loading

jcouv commented Jan 19, 2018 •

edited

Loading

AlekseyTs Jan 19, 2018 •

edited

Loading

AlekseyTs Jan 19, 2018 •

edited

Loading

jcouv Jan 19, 2018 •

edited

Loading

AlekseyTs Jan 19, 2018 •

edited

Loading