There are a couple of other MethodSymbol derived types that don't override these members:

• FunctionPointerMethodSymbol: probably not important because they cant' have attributes
• ReducedExtensionMethodSymbol: not used for compilation but won't this impact binding information?
• SynthesizedIntrinsicOperatorSymbol : unsure if this needs to be accounted for or not

Think the first two are fine but unsure about the third. Did you verify this didn't also need the override?

FunctionPointerMethodSymbol: probably not important because they cant' have attributes

Agreed, will probably refrain from overriding them due to no attributes.

SynthesizedIntrinsicOperatorSymbol : unsure if this needs to be accounted for or not

I do not think such methods would participate in NotNull/MemberNotNull

ReducedExtensionMethodSymbol: not used for compilation but won't this impact binding information?

I don't 100% understand the question. I do not think semantic model will be affected because we don't use these symbols to provide nullable public API information (e.g. nullable flow state for an expression).

I could see extension methods participating in NotNull, since it only concerns parameters), so let's add a test.

• edit: This PR only affects [MemberNotNull(...)], [MemberNotNullWhen(true, ...)], and [MemberNotNullWhen(false, ...)] scenarios. Looking at the [NotNull] tests, I think the coverage is adequate, so will not do anything for it in this PR.

Extension methods in reduced form should not participate in MemberNotNull in the "intuitive" way, since LDM decided that such attributes on extension methods would only be referencing members of the containing type of the extension method. We could conceivably test something like:

class C
{
    public string? _field;
}

static class Ext
{
    public static string? _field;

    [MemberNotNull("field")]
    public static void AssertFieldNotNull(this C c) { if (_field == null) throw null!; }
}

class Program
{
    void M(C c)
    {
        c.AssertFieldNotNull();
        Ext._field.ToString(); // no warning?
        c._field.ToString(); // warning
    }
}

As you can see, it's a really weird scenario--but good to test.

ReducedExtensionMethodSymbol: not used for compilation but won't this impact binding information?

I do not think semantic model will be affected because we don't use these symbols to provide nullable public API information (e.g. nullable flow state for an expression).

I am not sure what exactly does is mean to use a symbol to provide nullable public API information. In general, Retargeting symbols and PE symbols are analogous and should be treated uniformly. Similar to PE symbols, we are not performing binding for them as for symbols that are coming from source, but from the usage point of view, they are no different than source and PE symbols. I.e. any analysis can run into them, and they should be able to provide necessary information.