Debug assertion failure in MethodSymbol.AsMember when called from NullableWalker.GetNullableOfTValueSlot

[sharwell]

MethodSymbol.AsMember assumes that the newOwner is not an error symbol. This can fail (cause a debug assertion) for the following caller:

roslyn/src/Compilers/CSharp/Portable/FlowAnalysis/NullableWalker.cs

Line 10710 in 3f00cca

valueProperty = getValue?.AsMember((NamedTypeSymbol)containingType)?.AssociatedSymbol;

It seems like it may be sufficient to add the following check to GetNullableOfTValueSlot, however this would potentially impact additional call sites:

if (containingType.IsErrorType())
{
    valueProperty = null;
    return -1;
}

[RikkiGibson]

It would be useful to know more specifically what triggers the failure. For example, a unit test which triggers the assertion through use of public APIs.

[sharwell]

@RikkiGibson I'm not sure what the trigger is. It appeared randomly in an experimental instance where Compilers.slnf was open. This one would typically occur shortly after opening a solution that restored documents that were open when the IDE closed.

[jjonescz]

I cannot reproduce this. And I don't see how the debug assert in AsMember could fail:

1. I assume this is about Debug.Assert(ReferenceEquals(newOwner.OriginalDefinition, this.ContainingSymbol.OriginalDefinition));
2. In GetNullableOfTValueSlot, we have already asserted Debug.Assert(containingType.IsNullableType());, i.e., containingType.OriginalDefinition must be the symbol System.Nullable<T>.
3. So when we call AsMember((NamedTypeSymbol)containingType), the newOwner.OriginalDefinition must be the symbol System.Nullable<T> and hence it will be equal to this.ContainingSymbol.OriginalDefinition (where this is the symbol for SpecialMember.System_Nullable_T_get_Value).

MethodSymbol.AsMember assumes that the newOwner is not an error symbol.

In general, I don't think AsMember minds error symbols. It mostly just calls new SubstitutedMethodSymbol which specifically handles error symbols in some asserts.