Work items and test plan for "tuple equality" feature

[jcouv]

Championed issue: dotnet/csharplang#190

Various scenarios:

• if (tuple1 == (1, 2)) ...
• if (nestedTuple == ...) ...
• if (nullableT1 == t2) ...
• if (nullableT1 == nullableT2) ...

Open issues and test ideas:

• Issue with this (issue Tuple equality: consider that struct this has side-effects and should be saved to temp #25488, PR Struct this should be saved to temp in tuple equality #25390)
• Add optimization with NullableAlwaysHasValue/NullableNeverHasValue (issue Tuple equality: remember which temps are never null and optimize lowering further #25487)
• Should we pro-actively block tuple operators in VB as well? (no, let overload resolution kick in, confirm with VB LDM) (Kathleen confirmed ok to leave unblocked)
• merge-fixups (PR Add suggested tuple equality tests #25486)
• IOperation and order of children (Implementing basic GetOperations on tuple equality #25374)
• Allow on 1-tuple (t8.Rest)? (no, remains disallowed)
• block EnC (Block EnC on and around tuple equality #25402)
• should we produce any warnings for name mismatch between elements of compared tuples? (Track and check names in tuple equality #25396)
• Should we block other operators (even user-defined), just in case? (no, let overload resolution kick in)
• Fix semantic model (Restore semantic model functionality in tuple comparisons #25297)
• Test with (default, default)
• Test with fix for default in comparison (Give default literals a type in tuple comparisons #25327)
• Update spec and implementation so that order is: (1) dynamic case, (2) tuple case, (3) regular overload resolution, (4) fail.
• Verify in IDE
• Open question about customer ==, & and true operators (answer: we'll apply conditional "truthiness/falsiness" on element-wise comparison results) (resolved in LDM on Feb 5th)
• Double-check what is the truthiness rule for dynamic (from type, not from expression)
• Test with element of tuple being bool?
• test that only implicit conversion operator will be recognized (explicit conversion operator fails)
• Capture behavior for d == tuple where d is dynamic and holding a type that has a user-defined comparison operator to tuple types
• Capture behavior for d1 == d2 where d1 and d2 are dynamic and holding tuple types (that may or may not be comparable statically)
• Scenarios with Rest of 1 element or ValueTuple'1 in general should be disallowed (they are not tuples)

Related SO question

[jcouv]

Test plan

• Test langver ( TestCSharp7_2 )

• Test different cardinalities of tuples ( TestTupleLiteralsWithDifferentCardinalities, TestTuplesWithDifferentCardinalities, TestNestedTuplesWithDifferentCardinalities)

• Nullable tuple to nullable tuple ( TestEqualOnNullableVsNullableTuples, TestNotEqualOnNullableVsNullableTuples)

• Nullable tuple to non-nullable tuple ( TestOnNullableVsNonNullableTuples , TestOnNullableVsNonNullableTuples3)

• Verify evaluation order ( TestEvaluationOrderOnTupleLiteral, TestEvaluationOrderOnTupleType, and other tests called "EvaluationOrder" should cover all the sub-bullets below)

  • Verify evaluation order in nested case
  • Verify order of evaluation from left to right
  • In (M(), ..) == (M(), ..), then M() is invoked as many times as referenced
  • All the elements are evaluated, regardless of short-circuiting
  • In ==, if the first element-wise comparison succeeds, we should continue to the second ( TestEvaluationOrderOnTupleLiteral )
  • Conversely, if the first element-wise comparison fails, the subsequent comparisons are skipped
  • Skipped and continuing applies in reverse for !=
  • Ensure when the conversion happen (they happen as part of the element-wise comparison and are subject to short-circuiting)
  • Test that == on tuple results in == on elements (and conversely for !=)
  • Test proper application of conversion to bool on the result of element-wise comparison
  • Test proper application of op_True operator on the result of element-wise comparison

• Verify converted types and element names in semantic model (various tests checking "ConvertedType")

• Appropriate warnings should be reported for element names mismatch, including nested cases ( TestElementNames )

• Behavior when ValueTuple type is missing ( TestWithoutValueTuple )

• Check that GetConstantValue returns nothing on tuple, but returns something on a constant element ( TestSimpleEqualOnTypelessTupleLiteral)

• Check GetTypeInfo on both operands (expressions and literals) and the elements (tests with "GetTypeInfo")

• Get GetDeclaredSymbol on a tuple literal involved in tuple comparison (tests with "GetDeclaredSymbol")

• Check unassigned usage of element in tuple comparison ( TestDefiniteAssignment)

  • Tests when assignment happens later within the comparison

• Check WrittenInside, AssignedInside, etc APIs from region analysis ( AnalysisOfTupleEquality)

• Test with any generic element (since no == can be declared, maybe falls back to object) ( TestGenericElement)

• Block in expression tree (TestInExpressionTree)

• Test ref returning APIs as elements ((refReturningFoo(), refReturningProperty) == (1, 2))
  nameof((..) == (...)) (TestRefReturningElements)

• Show IL for checked and unchecked (TestChecked, TestUnchecked)

  • Check that checked/unchecked context affects: ((byte)0xFF + (byte)0xFF, ....) == (...)

• Try to pass the comparison as ref or out argument (it's just an RValue) (TestAsRefOrOutArgument)

• Use pointers as elements (should fail because pointers not allowed as type arguments) (TestWithPointer)

• Test (M(out var x), x) == (1, 2) (works) and (x, M(out var x)) == (1, 2) (error) (TestDefiniteAssignment2)

• Test anonymous types as elements ( TestWithAnonymousTypes, TestWithAnonymousTypes2)

• Test in a query (in where condition) (TestInQuery)

• Test that user-defined == on ValueTuple is ignored ( TestTupleEqualityPreferredOverCustomOperator )

• Test that comparison on dynamic results in dynamic invocation of ==. It will succeed at runtime if there is an operator, and will fail at runtime if there is not operator== on the types involved. ( TestNonBoolComparisonResult_WithTrueFalseOperators for success case, TestDynamic_WithBadType for failure case)

• Test that conversions to tuple and Deconstruct methods do not play a role (goes to resolution) ( TestEqualityOfTypeConvertingToTuple, TestComparisonWithDeconstruction )

• Test special comparisons null to null, null to default, default to default,

• Test element-wise comparison involving expressions that don't have a type (like lambdas or method groups, null, typeless tuples, ) (TestFailedInference )

IDE

• Test formatting (Julien verified manually)
• Test NormalizeWhitespaces
• Check UpgradeProject offered (Julien verified manually, see screencap below)
• Check soft-completion triggered in this context (Julien verified manually)
• Test highlighting and GoToDef and FAR of tuple elements (Julien verified manually, see screencap below)
• Extract (method and local) and inline elements and tuples (Julien verified manually, filed Tuple equality: ExtractMethod on typeless tuple in tuple equality produces bad code #25475 for bug on ExtractMethod on tupleless tuple)
• Rename of tuple elements (Julien verified manually, see screencap below)
• ([|a:|] a, 1) == ... (the "a:" should be offered to be simplified) (Julien verified manually, see screencap below)

Spec

• Add details to the conversion/operator for truthiness
• Clarify "As of C# 7.2, such ..." to say "unless there is a user-defined operator=="
• Spec should talk about S? compared to null and null compared to null
• Describe warning on names mismatch
• Add tuple comparison to test plan

[jcouv]

Tagging @AlekseyTs to do one pass of checking the marks based on tests names I provided. Thanks

[jcouv]

UpgradeProject:

Highlighting:

No Extract Local offered when tuple is typeless (correct), but Extract Method is offered (incorrect):

Extract Local produces code with a name mismatch warning:

Renaming of expression in tuple works:

Redundant tuple element name is offered to be simplified:

[jcouv]

@AlekseyTs Tuple equality is blocked on making progress on checking test plan.