Handling remaining PROTOTYPE markers in features/tuples branch

[jcouv]

Filed the following issues:

• Correct the evaluation order of conversions in deconstructions Correct the evaluation order of conversions in deconstructions #12400
• Optimize the parsing ahead for deconstruction-declarations to avoid allocations Optimize the parsing ahead for deconstruction-declarations to avoid allocations #12399
• Verify the behavior of dynamic in deconstructions Verify the behavior of dynamic in deconstructions #12398
• Parsing ahead for 'for' and 'foreach' ambiguities should recognize deconstructions Parsing ahead for 'for' and 'foreach' ambiguities should recognize deconstructions #12402
• Support typeless tuple literals in deconstruction declarations Support typeless tuple literals in deconstruction declarations #12410

I spent some time today trying to come up with a better solution for the last one, but after discussion with Vlad, I prefer to unblock the merge back to master and resolve the difficult language questions later. For now, I report errors if you try to use typeless tuple literals in a d-declaration (which is better than previous crashing behavior).

@dotnet/roslyn-compiler for review.
Related to #11299

[jaredpar]

How do we distinguish between the case:

• RHS is (null, null) and hence has no type
• RHS is in error and hence has no type.

In the latter case I assume we wouldn't want to go down this code path.

[jcouv]

When RHS is in error, its type is ErrorType (not null) which is already handled below (by DeconstructIntoStep). Added a test explicitly for this.

[jaredpar]

Do we have a good rule for when errors will cause Type to be ErrorType and when it will be null? Having both without a justification for when to choose one or the other make it harder to review code.

[jcouv]

That's a good question. I haven't heard any. So far, the cases I encountered where Type was null is in the expression null and also typeless tuples (() => {}, null).
I filed issue #12428 and will follow-up on that question separately.

[jcouv]

@dotnet/roslyn-compiler Please review. I want to merge the deconstruction feature back into the master branch before lunch.

[jaredpar]

[VSadov]

LGTM