File types binding

[RikkiGibson]

Related to #60819

I recommend disabling whitespace diffs when reviewing.

Implements the following sections of the spec (dotnet/csharplang#6011):

No accessibility modifiers can be used in combination with file on a type.

file types can only appear in signatures or as base types of other file types

@jcouv @cston for review

I'm particularly wondering if the way I'm doing lookup, and the way I'm getting the "associated syntax tree" from a binder, is correct.

[jcouv]

We should test accessibility restrictions on record positional members as well.

[jcouv]

Some more test ideas:

1. Do we have tests with aliases of file-types or including file-types?
2. File-type containing extension methods

[RikkiGibson]

We should test accessibility restrictions on record positional members as well.

See test PrimaryConstructor_01.

[RikkiGibson]

Added test Alias_01.

[cston]

is SourceMemberContainerTypeSymbol { IsFile: true }

Will we get here with a member of a file type? If so, should BestSymbolLocation.FromFile be returned in that case?

[RikkiGibson]

I think we might, in some cases where the member access is not qualified. The only relevant case I can think of, though, involves using static.

// File1.cs
using static C.D;

M();

file class C
{
    public class D
    {
        public static void M() { }
    }
}

// File2.cs
class C
{
    public class D
    {
        public static void M() { }
    }
}

I'll add the test. Let me know if any other scenarios come to mind that might hit this issue.

[RikkiGibson]

I added this test and it "just worked". I suspect this is because we "broke the tie" when binding the using static C.D, and binding the call is just a simple lookup within that.

[jcouv]

nit: do we think this will get re-used? If not consider making this a local function at single call-site

[RikkiGibson]

I thought this might get reused in another place where we report redundant symbols, but it didn't end up being the case. Moving to local function.

[jcouv]

nit: consider adding void M2(C c) { } // ok as well in this test (unless covered elsewhere)

[jcouv]

// expectedOutput: 2

nit: I would have used a PROTOTYPE marker, but I think it's fine. Let's remember to hunt down every such instance

[jcouv]

LGTM Thanks (iteration 14)

[cston]

Should we test base references, in error scenarios?

// file1.cs
file class Base
{
    public Base(int i) { }
}
partial class Derived : Base
{
}

// file2.cs
partial class Derived
{
    Derived() : base(0) { }
}

// file1.cs
file class Base
{
    public virtual void F1() { }
}
partial class Derived : Base
{
    public override void F1() { }
}

// file2.cs
partial class Derived
{
    void F2() { base.F1(); }
}

[RikkiGibson]

I would like to add these onto the test plan and add them in a subsequent PR.

[RikkiGibson]

Added a line to #60819.

[cston]

Program.

The qualifier isn't needed is it? Just confirming.

[RikkiGibson]

The meaning of the program isn't changed, but the method of binding is changed. Here we lookup the symbols directly in the Program type rather than in a binder which contains the members of Program. I think I added this to address the issue discussed in #60977 (comment).

[RikkiGibson]

Failing tests are unrelated to my change. #61017