Fix type parameter scoping for local functions

[jcouv]

... and parameter scoping for lambdas.

Reviving PR #59968 to establish correct baseline for nameof(parameter) work (draft PR). Thanks @Youssef1313 for this fix (I just added more tests)
Fixes #59775

Based on implementation, the rule for type parameters is that they are in scope in return type, type parameters and parameters area (see BinderFactoryVisitor.VisitMethodDeclaration), but not the method's attribute list. For expressions that bind a type (attribute [T], typeof(T), sizeof(T), default(T)) the type parameter will be found. But for identifiers, the type parameter will be skipped outside of nameof (see IsInMethodBody/IsInsideNameOf logic in BindIdentifier).
The spec (see pointers collected in nameof(parameter) spec) does not capture those subtleties.

Problem scenario 1 (parameter scoping for lambdas, fixed by change in LambdaSymbol.cs):

class C
{
    void M()
    {
        // error CS1503: Argument 1: cannot convert from 'int' to 'string'
        var _ = void ([My(parameter)] int parameter) => throw null;
    }
    // error CS0103: The name 'parameter' does not exist in the current context
    void M2([My(parameter)] int parameter) => throw null;
}

Problem scenario 2 (type parameter scoping for local functions, fixed by change in LocalFunctionSymbol.cs):

class C
{
    void M()
    {
        local<object>();

        [My(nameof(TParameter))] // works, but why?
        void local<TParameter>() { }
    }
    
    [My(nameof(TParameter))] // error CS0103: The name 'TParameter' does not exist in the current context
    void M2<TParameter>() { }
}

Problem scenario 3 (type parameter scoping for local functions, fixed by change in SourceTypeParameterSymbol.cs):

class C
{
    void M()
    {
        local<object>();

        // error CS0103: The name 'TParameter' does not exist in the current context
        void local<[My(TParameter)] TParameter>() => throw null;
    }

    // error CS0119: 'TParameter' is a type, which is not valid in the given context
    void M2<[My(TParameter)] TParameter>() => throw null;
}

After this PR, there remains a problem with scoping of type parameters on local function (the IsInMethodBody/IsInsideNameOf filter doesn't work properly on local functions).
Filed #60110
Example:

class C
{
    void M()
    {
        local<object>(0);

        // error CS0119: 'TParameter' is a type, which is not valid in the given context
        void local<TParameter>([My(TParameter)] int i) => throw null;
    }

    // error CS0103: The name 'TParameter' does not exist in the current context
    void M2<TParameter>([My(TParameter)] int i) => throw null;
}

After this PR, there remains a problem with LookupSymbols of type parameter in nameof in certain positions. See tests in PR for details. Filed #60194

[jcouv]

@dotnet/roslyn-compiler for review. Thanks

[AlekseyTs]

@jcouv Could you please clearly state what scoping rules do we want to have?

---

In reply to: 1067279846

---

In reply to: 1067279846

[AlekseyTs]

Done with review pass (commit 1)

[jcouv]

Added the scoping rules in OP

---

In reply to: 1067279846

[AlekseyTs]

        Binder binder,

Consider renaming this parameter as well

---

In reply to: 1068087746

---

Refers to: src/Compilers/CSharp/Portable/Symbols/ConstraintsHelper.cs:347 in 6ad91b0. [](commit_id = 6ad91b0, deletion_comment = False)

[AlekseyTs]

Done with review pass (commit 4)

[jcouv]

@AlekseyTs please take another look. Added some semantic model validation and fix.
OP was updated to reflect a bug that remains in semantic model scenario after this PR (filed #60194).

[AlekseyTs]

&& LookupPosition.IsInLocalFunctionTypeParameterScope(position, function.Syntax)

It looks like this is a more strict check than the one we perform before assigning to ownerOfTypeParametersInScope. Consider moving this check there as a replacement for the current check. #Closed

[AlekseyTs]

It looks like this is a more strict check than the one we perform before assigning to ownerOfTypeParametersInScope. Consider moving this check there as a replacement for the current check.

The check was not moved (as suggested), but was duplicated.

[AlekseyTs]

Done with review pass (commit 5)

[AlekseyTs]

Done with review pass (commit 6)

[RikkiGibson]

I'm confused by this, are we expected to find it in the attribute when the TParameter is used inside typeof, but not when it's used by itself?

[jcouv]

I agree the rules aren't quite as regular as I would have expected, as identifier lookups and type lookups (attribute type, typeof, etc) behave differently.

Here are the current rules, inferred from implementation:

the rule for type parameters is that they are in scope in return type, type parameters and parameters area (see BinderFactoryVisitor.VisitMethodDeclaration), but not the method's attribute list. For expressions that bind a type (attribute [T], typeof(T), sizeof(T), default(T)) the type parameter will be found. But for identifiers, the type parameter will be skipped outside of nameof (see IsInMethodBody/IsInsideNameOf logic in BindIdentifier).

[RikkiGibson]

To be clear, did you write that out just now or quote from somewhere?

[jcouv]

I just wrote that out (copied from OP). The spec does not capture those subtleties :-/

[AlekseyTs]

LGTM (commit 8)