Work items and test plan for "tuple equality" feature

[jcouv]

Championed issue: https://github.com/dotnet/csharplang/issues/190

Various scenarios:

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

Open issues and test ideas:

• [x] Issue with this (issue https://github.com/dotnet/roslyn/issues/25488, PR https://github.com/dotnet/roslyn/pull/25390)
• [x] Add optimization with NullableAlwaysHasValue/NullableNeverHasValue (issue https://github.com/dotnet/roslyn/issues/25487)
• [x] 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)
• [x] merge-fixups (PR https://github.com/dotnet/roslyn/pull/25486)
• [x] IOperation and order of children (https://github.com/dotnet/roslyn/pull/25374)
• [x] Allow on 1-tuple (t8.Rest)? (no, remains disallowed)
• [x] block EnC (https://github.com/dotnet/roslyn/pull/25402)
• [x] should we produce any warnings for name mismatch between elements of compared tuples? (https://github.com/dotnet/roslyn/pull/25396)
• [x] Should we block other operators (even user-defined), just in case? (no, let overload resolution kick in)
• [x] Fix semantic model (https://github.com/dotnet/roslyn/pull/25297)
• [x] Test with (default, default)
• [x] Test with fix for default in comparison (https://github.com/dotnet/roslyn/pull/25327)
• [x] Update spec and implementation so that order is: (1) dynamic case, (2) tuple case, (3) regular overload resolution, (4) fail.
• [x] Verify in IDE
• [x] 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)
• [x] Double-check what is the truthiness rule for dynamic (from type, not from expression)
• [x] Test with element of tuple being bool?
• [x] test that only implicit conversion operator will be recognized (explicit conversion operator fails)
• [x] Capture behavior for d == tuple where d is dynamic and holding a type that has a user-defined comparison operator to tuple types
• [x] Capture behavior for d1 == d2 where d1 and d2 are dynamic and holding tuple types (that may or may not be comparable statically)
• [x] Scenarios with Rest of 1 element or ValueTuple'1 in general should be disallowed (they are not tuples)

Related SO question

[jcouv]

Test plan

• [x] Test langver ( TestCSharp7_2 )

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

• [x] Nullable tuple to nullable tuple ( TestEqualOnNullableVsNullableTuples, TestNotEqualOnNullableVsNullableTuples)

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

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

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

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

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

• [x] Behavior when ValueTuple type is missing ( TestWithoutValueTuple )

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

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

• [x] 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)

• [x] 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)

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

• [x] 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)

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

• [x] Test special comparisons null to null, null to default, default to default,

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

IDE

• [x] Test formatting (Julien verified manually)
• [ ] Test NormalizeWhitespaces
• [x] Check UpgradeProject offered (Julien verified manually, see screencap below)
• [x] Check soft-completion triggered in this context (Julien verified manually)
• [x] Test highlighting and GoToDef and FAR of tuple elements (Julien verified manually, see screencap below)
• [x] Extract (method and local) and inline elements and tuples (Julien verified manually, filed https://github.com/dotnet/roslyn/issues/25475 for bug on ExtractMethod on tupleless tuple)
• [x] Rename of tuple elements (Julien verified manually, see screencap below)
• [x] ([|a:|] a, 1) == ... (the "a:" should be offered to be simplified) (Julien verified manually, see screencap below)

Spec

• [x] Add details to the conversion/operator for truthiness
• [x] Clarify "As of C# 7.2, such ..." to say "unless there is a user-defined operator=="
• [x] Spec should talk about S? compared to null and null compared to null
• [x] Describe warning on names mismatch
• [x] 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.

[jcouv]

@AlekseyTs I've added most of the remaining tests in PR https://github.com/dotnet/roslyn/pull/25486 before the feature was merged back to dev15.7.x branch. I've update the speclet as discussed. The remaining known issues (like struct this and optimization for always/never null) are tracked in individual issues.

I'll go ahead and close this umbrella issue.