Add support for top level statements

[RexJaeschke]

No description provided.

[KalleOlaviNiemitalo]

Should this say that the generated name is readable via CallerMemberNameAttribute?

System.Console.WriteLine(WhoAmI()); // outputs "<Main>$"

System.Action action = () => System.Console.WriteLine(WhoAmI());
action(); // outputs "<Main>$" again, not the name of the method generated for the lambda

string WhoAmI(
    [System.Runtime.CompilerServices.CallerMemberName]string member = null)
{
    return member;
}

[RexJaeschke]

@KalleOlaviNiemitalo, I confirm that the generated name can be found, but it's not clear to me how one might make use of that.

[KalleOlaviNiemitalo]

It might be best to add something about this to the specification of CallerMemberNameAttribute, to clarify that the name of the generated method is substituted even though it does not occur in the source code. Because this doesn't work like in lambda expressions where the user-specified name is used even though the code is generated to a differently-named method.

using System;
using System.Runtime.CompilerServices;

class C
{
    void M(int i)
    {
        // calls N(i, "M") even though the call is in a method named something like <M>b__0
        Action a = () => N(i);
    }
    
    static void N(int i, [CallerMemberName] string mem = null)
    {
    }
}

[RexJaeschke]

At the end of line 73, I added the following sentence:

It is, however, available via the attribute System.Runtime.CompilerServices.CallerMemberName.

Also, in that attribute's section, I added

(In the case of a function invocation from a top-level statement (§top-level-statements), the member name is that generated by the implementation.)

[RexJaeschke]

@KalleOlaviNiemitalo Do these changes resolve this conversation?

[BillWagner]

Closed in favor of #1454