Test plan for "file types"

[RikkiGibson]

Proposal: dotnet/csharplang#6011
Spec: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/file-local-types.md

Compiler

• type named @file exists
• type in nested namespace can hide file-type: file class C { } namespace N { class C { } class D { ... use unqualified "C" (ie. type N.C) ... } }
• SyntaxNormalizer
• file type "var" (or some other contextual keyword) declared
• SPEC: disallowed in global using (see GlobalUsingStatic_01)
• add modifier to compiler test plan
• file-interface can be implemented (implicitly or explicitly), but not when signature leaks file-type (see InterfaceImplementation_*)
• type named "file" disallowed (should be error)
• top-level local function named "file" exists
• file-type allowed in attribute type
• spec
• modifier only allowed in new LangVer (see LangVersion)
• modifier only allowed on top-level types (see Nested_*, AccessThroughType_*)
• modifier can only be specified once (see DuplicateModifiers_01)
• modifier allowed on various kinds of types:
  • class
  • struct,
  • record, record struct(seePrimaryConstructor_01`)
  • interface (see InterfaceImplementation_02)
  • enum (see FileEnum_*)
  • delegate
• access modifiers disallowed on file-types (see AccessModifiers_01)
• duplicate file-types are disallowed
• file-type can be static (see StaticFileClass)
• file-type can be generic (see Generic_01)
• partial file-types in same file are the same type (see Duplication_04)
• partial file-types in different files are different types (see Duplication_05)
• file-type only allowed in base type of file-types (top-level or nested in generic or tuple) (see BaseClause_*)
  • generic base type instantiated with file-type?
  • using an alias as base (see Alias_01)
• file-type can have a base type or implement an interface (see Nested_06, BaseClause_02)
• file-type only allowed in signatures within file-types (see SignatureUsage_*, PrimaryConstructor_01)
  • positive cases?
• file-type as type constraint
  • on method (see Constraints_01)
  • on various other declarations: types, ...
• file-type can be accessed with unqualified or qualified name (see AccessThroughNamespace_*)
• file-type can be accessed via using, static using, but not global using (see AccessThroughGlobalUsing_*, GlobalUsingStatic_01, UsingStatic_*)
• file-type can be accessed from top-level statements (see TopLevelStatements)
• file-types can introduce extension methods (see ExtensionMethod_*)
• file-types of same name can be declared in various nested namespaces (usual scoping rules apply)
• types can be shadowed and there's no way to access shadowed types
• file-type cannot be accessed from another file
  • file class C { } class Program { class C { } ... method with usage of inner class C ... }
  • file class C { } class Program<C>{ ... method with usage of type parameter C ... }
  • file class C { } class Program<C, T> where T : C { }
  • file record C(C x);
  • file class C<T> where T : C { }
• file-type can be used in various locations that allow types:
  • locals,
  • constraints (methods, types, delegates),
  • interface (see BaseClause_02)
  • attributes (see FileEnum_02)
  • typeof,
  • nameof
  • alias (see Alias_01)
  • base type (file class Outer { class Inner : Outer { } }
  • file class Outer { class Inner : Base<Outer> { } }),
  • lambdas (see Lambda_01)
  • local functions (see LocalFunction_01)
  • anonymous types
  • cref (see Cref_*)
  • ...
• SymbolDisplay shows unspeakable name (see SymbolDisplay)
  • File types emit #61646 (comment) Parse the emitted file type name in order to display in a similar fashion as the file type in source
• Scripting (see Script_01)
• EE (done in PR File types EE support #62812)
• Semantic model (LookupSymbols, GetSymbolInfo) (see SemanticModel_*)
• Speculation (see Speculation_01)
• Base reference in partial error scenario File types binding #60977 (comment)
• PDB verification (no changes in initial design)
• public API: should we have bool INamedTypeSymbol.IsFile? Possibly SyntaxTree? INamedTypeSymbol.AssociatedSyntaxTree?
• public API: should we have public SymbolDisplayOptions to show the associated file of a named type? e.g. NS.MyClass@MyFile.
• GetTypeByMetadataName (see GetTypeByMetadataName_*)
  • Test getting a retargeted file type from source using its metadata name
  • File types emit #61646 (comment) Test when MetadataTypeName.ForcedArity is specified
• Confirm whether we should have SymbolDisplayCompilerInternalOptions.IncludeContainingFileForFileTypes
• IsFile should be false on a nested type with file modifier

Language

• LDM question: allow file types in signatures of explicit interface implementations within non-file types? e.g. class C { void SomeInterface.M(FileType ft) { } } File types binding #60977 (comment) (answer: no)

Productivity

• completion for file (done in PR File types IDE changes #62215)
• colorization/classification for file (verified manually)
• formatting/spacing for file (verified manually)
• nav bar disambiguation when regular type and file-type with same name are in the current file (verified manually)

[tmat]

We should also consider scope of the type declaration in interactive submissions.

Defining the type in one submission and accessing it in another one should probably work:

> file class C {}
> new C()
> file class C {} // should hide original definition of C

However, each submission has a different file name (e.g. Submission#0, Submission#1, etc.).

If a file type is defined in a .csx file that is then loaded to another one the type should not be accessible:

C.csx:

file class C {}

> #load "C.csx"
> new C(); // error

[jcouv]

Spotted one spec gap (Rikki will update spec). Otherwise the test coverage is pretty comprehensive. Only a couple minor bullets were not checked. I'll go ahead and close the test plan.

[RikkiGibson]

A few missing tests were noted in recent discussion with @AlekseyTs.

• What happens when we try to use a file-type by name in -main:<type>. Test with both its source name and metadata name.
• What happens when partial file class is combined with top-level-statements. SharpLab.
• What happens when partial file class and partial class are used together in the same file. (related to the previous point). SharpLab
  • I don't think we're sure what should happen here. It feels like a 'file class' never has the same name as a non-file class, in a sense, so maybe it doesn't make sense to group them, and we should require repeating the file modifier in all the partial declarations of a file type. May need to confirm with LDM.