Test plan for "covariant returns" #43188
Labels
Area-Compilers
New Language Feature - Covariant Returns
Permit an override to return a more specific reference type
Test
Test failures in roslyn-CI
Milestone
Championed issue: dotnet/csharplang#49
Spec: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-9.0/covariant-returns.md
Runtime spec: https://github.com/dotnet/runtime/blob/master/docs/design/features/covariant-return-methods.md
Test plan
Test the following part of the specification: "The override method must have have a return type that is convertible by an identity or implicit reference conversion to the return type of the overridden base method."
Test the following part of the specification: "The override method must have have a return type that is convertible by an identity or implicit reference conversion to the return type of every override of the overridden base method that is declared in a (direct or indirect) base type of the override method."
Coming from references:
Test compile and runtime behavior for the following attempts to override:
Test the following part of the specification: "the override method's return type must be at least as accessible as the override method." This constraint permits an override method in a private class to have a private return type. However it requires a public override method in a public type to have a public return type.
Test scenarios outlined above for properties.
Test the following part of the specification: "there shall be an identity conversion or (if the inherited property is read-only) implicit reference conversion from the type of the overriding property to the type of the inherited property."
Test the following part of the specification: "Callers of the method or property would statically receive the more refined return type from an invocation." Cover both runtime and compile time effect of this. Verify IL generated.
Symbol model
Metadata import
Sealing overriding with a covariant return override. Verify that the compiler respects the sealing (i.e. doesn't allow to override the member in a more derived type). Verify that runtime respects the sealing.
Confirm ref returns are not subject to the covariant return changes.
Test binary compatibility scenarios when overrides are added or removed in bases in new version of the libraries. Cover compile and runtime behavior.
Language version should be checked for an attempt to take advantage of the feature
Runtime capability should checked for an attempt to take advantage of the feature
Verify cannot use covariant return for an interface implementation
Test interop with VB
Test IDE behavior around overriding.
Test that we don't attempt to copy custom modifiers for return type when type changes.
When the return type changes, make sure warnings about nullability mismatch in the type are reported as appropriate. Some examples of the scenarios:
Tests not yet implemented
BinaryCompatibility_*
) but with a method newly inserted into the hierarchy (in place ofMid.M
) wherenew virtual
method, we assume it will be newSlotnew
but not virtual, we assume it will be newSlothidebysig
flag in metadataBinaryCompatibility_03
TestAmbiguousOverridesRefOut
inCodeGenOverridingAndHiding
are tested on runtimes that support covariant returns (i.e. handle methodimpl correctly).PreserveBaseOverridesAttribute
to the specTests believed to already exist
TestVBConsumption_01
]InDelegateCreation_01
]InExpressionTree_01
]base.M()
calls of a covariant override. [Most of the new tests]COut<object?>
vs.COut<string!>
and some permutations). [NestedVariance_01
,NestedVariance_02
]CovariantReturnTests.CovariantReturns_WritableProperties
]CovariantReturnTests.CovariantReturns_13
]CovariantReturns_14
,CovariantReturns_15
]CovariantReturns_16
]CovariantReturnTests
]TestVBConsumption_*
]Runtime:
RequireMethodImplToRemainInEffectAttribute
)The text was updated successfully, but these errors were encountered: