Pattern C# 7.0 - 11.0

[wise0704]

References:

• C# 7.0 - Patterns
• C# 8.0 - Recursive Pattern Matching
• C# 9.0 - Pattern matching enhancements
• C# 10.0 - Extended property patterns
• C# 11.0 - List patterns

Combined grammar from 7.0-11.0:

ANTLR

```antlr pattern : disjunctive_pattern ; disjunctive_pattern : disjunctive_pattern 'or' conjunctive_pattern | conjunctive_pattern ; conjunctive_pattern : conjunctive_pattern 'and' negated_pattern | negated_pattern ; negated_pattern : 'not' negated_pattern | primary_pattern ; primary_pattern : parenthesized_pattern | relational_pattern | constant_pattern | declaration_pattern | var_pattern | type_pattern | positional_pattern | property_pattern | discard_pattern | list_pattern | slice_pattern ; parenthesized_pattern : '(' pattern ')' ; relational_pattern : '<' relational_expression | '<=' relational_expression | '>' relational_expression | '>=' relational_expression ; constant_pattern : constant_expression ; declaration_pattern : type simple_designation ; var_pattern : 'var' designation ; type_pattern : type ; positional_pattern : type? '(' subpatterns? ')' property_subpattern? simple_designation? ; subpatterns : subpattern | subpattern ',' subpatterns ; subpattern : pattern : subpattern_name ':' pattern ; subpattern_name : identifier | subpattern_name '.' identifier ; property_subpattern : '{' '}' | '{' subpatterns ','? '}' ; property_pattern : type? property_subpattern simple_designation? ; simple_designation : single_variable_designation | discard_designation ; discard_pattern : '_' ; list_pattern : '[' (pattern (',' pattern)* ','?)? ']' simple_designation? ; slice_pattern : '..' pattern? ; ```

Note:

Everything should work regardless of line breaks or whitespaces. One problem is there's no way to differentiate x is int? a and x is int ? a : b while fully supporting line breaks. Current solution is to assume no whitespace before ? means nullable, and conditional statement otherwise.

Todo:

• Implementation
  • [x] Pattern combinators
  • [x] parenthesized_pattern → not implemented — unable to distinguish the begin token ( from positional_subpattern, but fortunately positional_subpattern is a superset of parenthesized_pattern (pattern within parentheses)
  • [x] relational_pattern
  • [x] constant_pattern
  • [x] declaration_pattern
  • [x] var_pattern
  • [x] type_pattern → use different logic from other type detections to allow line breaks, figure out what to do with question mark
  • [x] positional_pattern
  • [x] property_pattern
  • [x] discard_pattern
  • [x] list_pattern
  • [x] slice_pattern
  • [x] is operator
  • switch statement
  • [x] case label
  • [x] when clause
  • switch expression
  • [x] pattern arm
  • [x] when clause
• [x] Existing tests pass
• Add new tests
  • is operator
  • [x] All patterns
  • switch statement
  • [x] All patterns
  • [x] when clause
  • switch expression
  • [x] All patterns
  • [x] when clause

Resolves #13, resolves #14, resolves #173 Related: #239

[wise0704]

I don't feel like writing tests to all these features they piled up over the years...

[wise0704]

Quick question @JoeRobich Why is .json the only file that's ignored? The other two files are also just outputs. https://github.com/dotnet/csharp-tmLanguage/blob/2759f6d64fff1bfb35e1e23df78fda373e7de3e7/.gitignore#L4

[JoeRobich]

Why is .json the only file that's ignored?

We should probably stop writing one out. The VS Code repo generates their own from our source. If it is actually useful to you, we should update the gulp script to stop trying to write the extra information that VS Code adds to their copy.

[JoeRobich]

I don't feel like writing tests to all these features they piled up over the years...

I opened a PR to add some tests to your branch. https://github.com/wise0704/csharp-tmLanguage/pull/1

[wise0704]

type-pattern now supports line breaks, but:

One problem is there's no way to differentiate x is int? a and x is int ? a : b while fully supporting line breaks. Current solution is to assume no whitespace before ? means nullable, and conditional statement otherwise.