Test plan for "extended property patterns"

[alrz]

Championed issue: dotnet/csharplang#4394
Spec: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/extended-property-patterns.md

Initial PR: #52139

Compilers

• Verify a conditional access is not allowed in place of the name
• IOperation and CFG (using { Prop1: { Prop2: pattern } } translation, see ExtendedPropertyPatterns_IOperation_*, ExtendedPropertyPatterns_IOperationOnMissing)
• Semantic Model (GetSymbolInfo, GetTypeInfo, see ExtendedPropertyPatterns_SymbolInfo_*)
• nullable analysis
  • do we learn from member accesses, i.e. not null state for nested members?
  • do we learn from pure null tests? (see OtherComparisonsAsPureNullTests_ExtendedProperties_PureNullTest)
  • nullable value types
• Pattern Explainer (do we give correct examples in a non-exhaustive match, see ExtendedPropertyPatterns_Explainer)
• definite assignment (mark read fields, see ExtendedPropertyPatterns_05)
• Verify all existing scenarios (where the name is optional or disallowed) work as expected with a member access (see ExtendedPropertyPatterns_ExpressionColonIn*)
• inaccessible properties/fields (see ExtendedPropertyPatterns_Inaccessible*)
• expression tree (see ExtendedPropertyPatterns_ExpressionTree)
• Language Version
• SyntaxNormalizer (see TestNormalizeExtendedPropertyPattern)
• Obsolete (see ExtendedPropertyPatterns_Obsolete*)
• Keep rejecting null-suppression and pointer access in patterns (issue Reject null-suppression operator in patterns #53484)
• Count checked fields as used (issue False warning: pattern matching on a field doesn't count as a use #52956)
• evaluation order
• static properties/fields (errors)
• API shape (unshipped, syntax)
• EnC (nothing special)
• exhaustiveness of switch expression
• spec: no formal commitment to only evaluate once

IDE

• Completion for nested members and patterns
  • Test completion with two possible bindings (see CompletionOnListPattern_FirstNested and test above)
• QuickInfo/GoToDef
• FindAllReferences on nested members
  • Add one highlight or rename test (see RenameExtendedProperty)
• formatting
  • Add an indentation test (see ExtendedPropertyPattern_Before and ExtendedPropertyPattern_After)
• TypeInferrer (see TestEnumInPatterns_SwitchStatement_ExtendedPropertyPattern)
• GenerateVariable (see TestPropertyPatternInCasePattern2)
• Add test for { A.B: MissingConstant$$ } (see TestConstantPatternInExtendedPropertyPattern)
• Offer to collapse pattern (is { P1: { P2: ... } } => is { P1.P2: ... }) (issue Offer to refactor into extended property pattern  #55545)

[alrz]

@333fred

chained member references for subpattern operation

Is this the right thing to do if we had nullable value types? In this case Member belongs to the underlying type, not the receiver. How do we want to reflect that in the operation tree?

[333fred]

Is this the right thing to do if we had nullable value types? In this case Member belongs to the underlying type, not the receiver. How do we want to reflect that in the operation tree?

We shouldn't represent these any differently in the operation tree from nested property patterns. It's a shorthand for writing, but the semantics are exactly the same as if the user wrote it out the long way. Thus, the IOperation tree should be identical. If a user cares about the syntax form used to write out the pattern, they can go back to syntax at that point.