Binder cycle leads to NullReferenceException
#63140
Comments
|
Never mind, it still repros there. |
|
@cston The issue is general (not specific to |
True, but if the only use is for |
|
We could potentially handle this by adding a |
Version Used: Tip of main
Steps to Reproduce:
See on sharplab. Run with
C# Next: ref fieldsas currently sharplab is broken for mainExpected Behavior:
Actual Behavior:
Root Cause
TL; DR This is a cyclic dependence issue in the binder. Attempting to resolve the type of generic nullable type parameter such as
T?while the interface mapping for its associated method is being built causes a cycle.The cycle begins when we try to build the [interface mapping(https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/interfaces#1765-interface-mapping) for type C. It is specified in source that C implements the interface I, so to build the interface mapping we must map all members of I to members of C.
So, for each method defined in I (in this case, there is only one:
I.M) we must do the following:- Search through members defined in C and its possible base types to see if they explicity implement the interface method
- We will find the single member
I.Mwhich is supposed to be an explicit interface implementation- This causes us to attempt to materialize the implementation map entry for
I.Msince on our first pass it will not be cached- This means that we need to ask the method
I.MofCif it has any explicit interface implementations- To do this, the
MethodSymbolforMhas to be materialized, which in this case involves constructing/binding its parameters- The construction of parameters means that we have to check for parameter errors (See
ParameterHelpers.ReportParameterErrors.- Since the type is marked as
scopedthis causes a particular condition inReportParameterErrorsto trigger, which means that the.Typefield of the parameter is evaluted. This means that we have to get the bound type of a generic type parameter (in this case,T?)- Since the type parameter is nullable, it becomes a
LazyNullableTypeParametersince we don't know if it will be a nullable value or a nullable reference. But we need the type now so we force resolution- This causes us to check if the method has any constraints on its type parameters
- This means we need to check the constraints of the method we are overriding (or implementing in this case)
- This requires that the
LazyNullableTypeParamterget its associated overriden method (SeeSourceTypeParameterSymbol.OverridenMethod)- This step needs to compute the explicit implementations for the overriding method. But the field
ExplicitImplementationsof the overriding method is exactly what we are already trying to compute, so it is null.The text was updated successfully, but these errors were encountered: