Allow nameof to access instance members.

[YairHalberstadt]

Fixes #40229

nameof is allowed to access instance members in a static context, and to capture ref / struct this variables. This fixes a bug where members of instance members could not be accessed inside a nameof in a static context.

The relevant part of the spec is this:

However, where the lookup described in Simple names and Member access results in an error because an instance member was found in a static context, a nameof_expression produces no such error.

For example, currently the following is allowed:

using System;
public struct C {
    public string P;
    public static string M1() => nameof(P);
    public Func<string> M2() => () => nameof(P);
    public Func<string> M3(ref string x) => () => nameof(x.Length);
}

But the following isn't:

using System;
public struct C {
    public string P;
    public static string M1() => nameof(P.Length);
    public Func<string> M2() => () => nameof(P.Length);
}

This PR fixes these cases.

There was also an inconsistency in the previous implementation, where the following was allowed:

public class C
{
    public C Prop { get; }
    public static void StaticMethod(){}
    public string M() => nameof(Prop.StaticMethod);
}

But this produces an error:

public class C
{
    public C Prop { get; }
    public static int StaticProp { get; }
    public string M() => nameof(Prop.StaticProp);
}

error CS0176: Member 'C.StaticProp' cannot be accessed with an instance reference; qualify it with a type name instead

It is probably a bug that this is allowed for methods, but this cannot be changed due to back compat. Whilst I'm not sure whether this is worth fixing on it's own for various reasons, I think it fits well enough under the umbrella of the other changes being made here that it's worth allowing in C#10 for consistency.

Things this PR doesn't fix

The following is still illegal:

public struct C {
    public string M();
    public static string M1() => nameof(M()); 
    public static string M2() => nameof(M().Length);
}

error CS0120: An object reference is required for the non-static field, method, or property 'C.M()'

This is because even if we removed that error, we would still get the following error:

error CS8081: Expression does not have a name.
error CS8082: Sub-expression cannot be used in an argument to nameof.

So I didn't think it worth fixing.

I also don't allow use of this and base in nameof since I'm not sure if that's a bug.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[YairHalberstadt]

@gafter I think you wrote this code originally. Was it intentional to not allow nameof(InstanceProperty.Member) in a static context, but allow nameof(InstanceProperty)?

[AlekseyTs]

I am not sure I agree with interpretation of the spec. I think the quote about Simple names and Member access talks about them at the top level of the named_entity part rather than about them on any level. In that sense errors about P in the example:

using System;
public struct C {
    public string P;
    public static string M1() => nameof(P.Length);
    public Func<string> M2() => () => nameof(P.Length);
}

are expected because, even though P is a simple name, it not the named_entity. Therefore, the exception doesn't apply.

[YairHalberstadt]

@AlekseyTs

If you look at the grammar given in the spec, both "P" and "Length" are parsed as named_entity

[AlekseyTs]

Here is the quote in context:

The meaning of the named_entity of a nameof_expression is the meaning of it as an expression; that is, either as a simple_name, a base_access or a member_access. However, where the lookup described in Simple names and Member access results in an error because an instance member was found in a static context, a nameof_expression produces no such error.

The paragraph is talking about the named_entity of a nameof_expression, i.e. the one in the grammar

nameof_expression
    : 'nameof' '(' named_entity ')'
    ; 

Not about any named entity

[alrz]

So either both of these should be an error or none?

public class C
{
    [Attr(nameof(Other.Length))] // error 
    public string Other;
    string M() => nameof(Other.Length); // ok
}

[alrz]

Ah I think attribute case is considered a static context so the error is correct.

[YairHalberstadt]

I've opened an issue on csharplang to clarify the meaning of the spec, and consider changing it in a future language version if the current implementation is not a bug: dotnet/csharplang#4037

[YairHalberstadt]

I've now changed this to only work in preview language version, thereby implementing dotnet/csharplang#4037

[333fred]

Done review pass (commit 3). I'm not certain what IDE features will be impacted by this, will need a buddy to advise. #Closed

[333fred]

Done review pass (commit 7). Looking good overall, couple of small comments. If the recursive tests do end up becoming an issue let me know on discord and I can help you troubleshoot. #Closed

[333fred]

@AlekseyTs for a second review.

[AlekseyTs]

@YairHalberstadt It looks like there are legitimate test failures and a merge conflict. Could you please address those?

[AlekseyTs]

Done with review pass (commit 14)

[333fred]

Moving this to draft to take it off the backlog. @YairHalberstadt, do you think you'll have time to address feedback here?

[YairHalberstadt]

@333fred probably not

[333fred]

Alright. We're going to have @jjonescz pick this up to get it across the finish line.

[AlekseyTs]

For some reason CodeFlow crashes while trying to load this PR. Could be due to very old commits in the PR. In order to confirm this theory, could you clone the branch in a new branch, rebase it on top of main and create a different PR from that new branch?

[jjonescz]

For some reason CodeFlow crashes while trying to load this PR. Could be due to very old commits in the PR.

Yes, happens to me, as well.

In order to confirm this theory, could you clone the branch in a new branch, rebase it on top of main and create a different PR from that new branch?

#67461

[AlekseyTs]

#67461

CodeFlow works for that PR. I suggest continue working in that branch.

[jjonescz]

CodeFlow works for that PR. I suggest continue working in that branch.

Alright. Closing this in favor of #67461.