[Umbrella] Improve EnC support for C#7 features

[tmat]

Scope 0:

• Disable EnC in presence of new VB nodes Disable EnC in presence of new VB nodes #14363 (not required)
• Signature comparison for tuples in method signatures EnC: disable edits of tuple types and their names on a method signature #14253
• Disable EnC in presence of new C# nodes
• Disable EnC in presence of C# 7 switch statement Disable EnC in presence of C# 7 switch statement #12380
• Edit-and-continue needs to be disabled for foreach loops that contain out vars Edit-and-continue needs to be disabled for foreach loops that contain out vars #12736

Scope 1:

• Reasonable diff function
  • Deconstruction (statement, new foreach, updated for) (PR Implement EnC distance function for deconstruction #13907)
  • Out var (I think this is N/A)
  • Switch
  • Local functions (should we need another level of comparison?)
  • Expression-bodied accessors, ctor, and dtor
• Disable EnC in presence of v7 syntax (deconstruction, tuple, out var, ref locals, local functions) for active methods

Scope 2:

• Distance computation for C# 7 nodes, tracking slots with newly introduced locals and temps

[gafter]

@jaredpar @AlekseyTs @agocke FYI

[DustinCampbell]

FWIW, it'd be great to have a future work item to add EnC support here.

[gafter]

In private email, I asked @tmat

what is the right way to make it so that changes to a method that uses certain new language features is a rude edit? Is this even possible?

He responded

It is certainly possible, on two levels. The big hammer is to disable analysis of a file containing any C# 7 syntax node. To do so a rude edit diagnostic should be added here (will need to add abstract method overridden by both C# and VB EnC analyzer). That will make sure we don’t even try to analyze any changes in that file, so the tree diffing code doesn’t need to be updated to account for new syntax nodes.

Alternatively we can add support for all new syntax nodes to the tree diffing code and only disallow editing active methods containing C# 7 features. That’d be less annoying for the user since they can at least step out of the method and edit it once it’s not active anymore (unless it’s an async or an interator method which we consider active all the time currently). To do so you can check out existing code in VB that’s reporting rude edits for active methods containing on-error-resume statements.

[jcouv]

Notes from our discussion on 2.0 scope:

• Scope 0 (min bar): no edit on any method that includes any new syntax node or a v7 switch syntax node; handle tuples in method signature (some diff work). SWAG 3w: some ramp-up, 1w coding, 1w testing
• Scope 1 (plan of record): no edit on active method that includes any new syntax node (or v7 switch). Edit on inactive methods with new nodes is allowed and we are able to do some reasonable diff function. SWAG: a couple of days to a week, depending on how fancy we get.
• Scope 2: no edit on active statement, but edit on inactive statement is ok (even if new syntax node is involved). We can enable new syntax nodes one by one. Deconstruction probably easiest, then pattern and out var. Didn’t SWAG.

[jcouv]

I think this issue here is superceded by #17891 (and in fact most of the C# 7.0 features, except for local functions, now work with EnC). So I'll close this as duplicate.