tuple-names.md

Test plan for "Infer tuple names" aka "tuple projection initializers"

This is a checklist for testing the implementation of dotnet/csharplang#415. I (@gafter) will check items off as I see they are handled in the implementation (currently in dotnet/roslyn#18374).

• We need a specish proposal that clearly describes the decision for key decision points. Once that is done I'll add additional bullets to this test plan.

There should be a positive test for each of the "golden" C# scenarios in dotnet/csharplang#370:

• (int, int) t = (x, y); // (int, int)
• (int a, int b) t = (x, y); // (int a, int b)
• var t = (x, y); // (int x, int y)
• var t = (x, x); // (int, int)
• var t = (n: x, x); // (int n, int x)
• var t = (x, 5); // (int x, int)
• var t = (x, x, y); // (int, int, int y) See TupleCreationWithInferredNames

There should be a positive test for corresponding "golden" VB scenarios:

• Dim t As (Integer, Integer) = (x, y) ' (Integer, Integer)
• Dim t As (a As Integer, b As Integer) = (x, y) ' (a As Integer, b As Integer)
• Dim t = (x, y) ' (x As Integer, y As Integer)
• Dim t = (x, x) ' (Integer, Integer)
• Dim t = (n := x, x) ' (n As Integer, x As Integer)
• Dim t = (x, 5) ' (x As Integer, Integer)
• Dim t = (x, x, y) ' (Integer, Integer, y As Integer)

Test language version:

• We should not infer tuple names in C# 7.0 or VB 15.0. See TupleCreationWithInferredNamesWithCSharp7
• We should infer tuple names in C# 7.1 and VB 15.3.
• We identified a breaking change for this feature. Write a program that displays different behavior depending on language version.
• Add a note to the compiler breaking changes document for the language change's effect on existing programs. See InferredNames_ExtensionInvokedInCSharp7ButNotCSharp7_1
• Ensure the "default" language version is C# 7.0, and the "latest" is C# 7.1. These tests may already exist in master.
• Similarly ensure "default" and "latest" versions for VB.

Tests specific to this feature:

• Test to ensure correct (per spec) behavior when an inferred name would be of the form

  • Item1 (both in the correct and incorrect position)
  • Item10 (both in the correct and incorrect position)
  • GetHashCode, Equals, ReferenceEquals
  • These same names are case-insensitive in VB.

• Test to ensure no name inferred for a user-defined operator invocation

• Test to ensure a name is inferred even if a user-defined conversion is applied after the expression

• Test the interaction of "common type" with inferred names.

• Test each of the syntactic constructs that cause a name to be inferred:

  • Identifer (local, parameter, field, property, event, enumeration constant)
  • expr.Identifier including this.Identifier and base.Identifier. I didn't test base
  • expr?.Identifier
  • value in a property setter
  • A declaration expression with a simple designator (see below)
  • Some other VB-specific contexts. Tested with method invocation.

• Test that other syntactic constructs to not cause a name to be inferred:

  • tuple literal
  • expr.M() (except in VB)
  • ( Identifier )
  • checked ( Identifier ) and unchecked ( Identifier )
  • default(Type)
  • A _ discard in deconstruction.

• Test that inferred names can come from the left-hand-side of a deconstruction

  • For a deconstruction-declaration like var (x, y) = (1, 2)
  • For a deconstruction-declaration like (var x, var y) = (1, 2)
  • For a deconstruction-declaration like (int x, int y) = (1, 2)
  • In nested scenarios
  • For a deconstruction assignment like (x, y) = (1, 2)

Where names are inferred, test the behavior of APIs

• GetDeclaredSymbol on the argument expression (probably should not declare the tuple element name)
• GetTypeInfo and GetSpeculativeTypeInfo
• Test the interaction of typeless tuples with inferred names is per spec. In this case inferred names are never used (there is no type to contain the inferred names).
• Though it would be an error to use an inaccessible member in a tuple expression, the APIs should still show the name as being inferred based on the syntax.
• Using a named constant (const declared member or local) should infer the name.
• If the tuple is typeless, e.g. contains a method group, there should be no inferred names (because there is no type into which it could be inferred).

IDE tests (see also the IDE test plan); each for both languages

• Is the inferred name colored appropriately at its use site?
• Does completion after dotting off a tuple literal include inferred names?
• Do inferred names show quick info when hovering on completion list items and uses? See known issues below.
• Does selecting an inferred identifier also highlight other references to it? (Only in C#)
• Does extract method of a tuple literal include inferred names in the return type?
• When using extract-method on an expression like x.y or y in a tuple literal, is it replaced by y: GeneratedMethod() to preserve the inferred element name?
• Same as previous two questions for introduce-variable (or is it generate-local?) and/or generate-field instead of extract-method.
• Does inline-temporary-variable introduce a tuple element name lost by the inlining? E.g. changing (temp, 2) to (temp: expression, 2)?
• Does go-to-definition from a use of an inferred element name navigate to the element of the tuple literal? See known issue in VB.
• Does find-all-references find other uses of the same inferred name?

Miscellaneous

• Complete this test plan (work in progress); The following references may be useful:
  • https://github.com/dotnet/roslyn/blob/master/docs/contributing/Compiler%20Test%20Plan.md
  • dotnet/csharplang#415 (champion issue)
  • https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md
  • The IDE test plan.

Know issues:

• VB does not handle GetSymbolInfo on tuple fields properly: dotnet/roslyn#16697
• hovering over tuple element shows sub-optimal QuickInfo: dotnet/roslyn#18371 (comment)