Test Plan for C# 9 pattern-matching improvements.

[gafter]

This is a placeholder for a test plan for the set of changes planned for pattern-matching in C# 9.

See dotnet/csharplang#2850 for a draft specification.

• Potential breaking changes
  • is (var x) _ is a tuple pattern
  • is and _ and o is or _ are type patterns
  • is string and and o is string or are type patterns
    • Behavior in earlier C# versions
• is (var x) is a parenthesized var pattern
• Language version on each new kind of pattern.
• Test the semantic model for the type pattern.
• Test IOperation for all new pattern forms.
• Test definite assignment under and pattern combinator.
• Verify which patterns/type permutations are allowed for relational patterns.
• Test byteValue is < 1000 should produce an error (1000 cannot convert to byte)
• Test expected behavior around subsumption for relational patterns of different types (e.g. < 0 and < 0f)
• Test subsumption of type patterns
  • x is BaseType and/or DerivedType
  • x is BaseType and/or UnrelatedType
  • x is SomeType and/or SomeInterfaceType
  • x is SealedType and/or SomeInterfaceType
• Diagnostic for unreachable/constant cases [See Warn for is-pattern using a relational pattern with a known result. #42501]
  • o is not var x
  • o is not _
  • short is > 65535
• Switch relational subsumption vs constant pattern, e.g.
  c# i switch { < 10 => ..., 1 => ... // error, subsumed
  • All constant types, (u)int, (s)byte, short, long, double, float, char
• Relational pattern on enums
  • Varying underlying
  • Error comparing to non-enum types
  • Subsumption uses domain of underlying type
• IL baseline for perf-sensitive compare e.g., ASCII check:

       c switch
       {
           < 'z' and > 'a' => "lower",
           < 'Z' and > 'A' => "upper",
           _ => "non-alphabetical",
       }

• Diagnostic differences between is type-pattern and is type expression
• Precedence of parenthesized pattern
  • spec observability of side effects in pattern tests? (a or (b and c))

IDE

• Verify completion and formatting for different kinds of patterns
• The refactoring from (object)x != null to x is object should be changed to produce x is not null

[alrz]

I wonder if we intend to catch these erroneous patterns (common mistakes, I suspect)

_ = a is >= 0 and <= 20;  // ok; valid range test
_ = a is <= 0 and >= 20;  // error; can never match
_ = a is >= 0 and >= 20;  // warn; left pattern is redundant
_ = a is <= 0 and <= 20;  // warn; right pattern is redundant
_ = a is <= 0 or <= 20;   // warn; left pattern is redundant
_ = a is >= 0 or >= 20;   // warn; right pattern is redundant
_ = a is >= 0 or <= 20;   // warn; always matches
_ = a is <= 0 or >= 20;   // ok; valid inverted range test