[API Proposal]: `ForTypesWithDirectBaseTypeOrInterface`

[Youssef1313]

Background and Motivation

It's a common scenario that source generators need to generate code for a type that inherits or implements an interface.

This scenario itself is divided into two scenarios:

• Direct inheritance
• Indirect inheritance

There might not be any way for the latter to be implemented efficiently, so this proposal is only about the former case (direct inheritance).

I believe it's possible to implement this API efficiently, though it's a non-trivial for generator authors to do. Besides that, the implementation inside the compiler could be more efficient as it could access some internals :)

Proposed API

namespace Microsoft.CodeAnalysis
{
     public struct SyntaxValueProvider
     {
+        public IncrementalValuesProvider<T> ForTypesWithDirectBaseTypeOrInterface<T>(string fullyQualifiedMetadataName, Func<BaseTypeDeclarationSyntax, CancellationToken, bool> predicate, Func<BaseTypeSyntaxContext, CancellationToken, T> transform);
     }

The BaseTypeSyntaxContext would be like this:

public readonly struct GeneratorAttributeSyntaxContext
{
    /// <summary>
    /// The syntax node for the declaration with the target base type
    /// </summary>
    public BaseTypeDeclarationSyntax TargetNode { get; }
 
    /// <summary>
    /// The symbol that has the requested base type or interface
    /// </summary>
    public ISymbol TargetSymbol { get; }
 
    // intentionally not including SemanticModel. I don't see how it will be important/used here.
}

Usage Examples

context.SyntaxProvider.ForTypesWithDirectBaseTypeOrInterface(
    "FullyQualifiedName",
    (node, ct) => node is ClassDeclarationSyntax,
    (context, ct) => CreateModel(context.TargetSymbol)
);

Open questions

What if there are two matching class declarations for the same symbol? We don't want to transform both nodes.

Alternative Designs

Risks

[Youssef1313]

cc @CyrusNajmabadi @333fred

[333fred]

I'm rather concerned about the usability of a library designed around this API. Inheritance, both direct and indirect, are the lingua franca of C#. Unless we can do both, I worry that we'd end up making end users lives worse with such a change.

[CyrusNajmabadi]

Note: transitive (while likely most valuable) is also very hard. Esp because to do it properly we need to understand (and cache) the inheritance hierarchy of metadata-types. IDE actually has such a system (we use it for 'go to impl'), but it's non-trivial, and def may not be "correct enough" for the needs the compiler would have.

[Youssef1313]

If the problem is metadata types, I think there is an approach that might work well.

Inaccurate pseudo-code, that just shows the idea.

Note 1: s_map here will be a static CWT<AssemblyIdentity, object> (the object here will "box" the immutable array, I guess boxing allocations might not be a concern here, but even if it is, there may be a way to get rid of it)

Note 2: The step to compute things from metadata is going to be very expensive, but it's run only once. I have tested a similar approach in practice, and it yielded very good performance results.

		var metadata = context.CompilationProvider.SelectMany((compilation, _) =>
		{
			var builder = ImmutableArray.CreateBuilder<CustomModelContainingTheInfoWeNeedFromMetadata>();
			foreach (var reference in compilation.References)
			{
				if (compilation.GetAssemblyOrModuleSymbol(reference) is IAssemblySymbol assembly)
				{
					if (!s_map.TryGetValue(assembly.Identity, out var output))
					{
						output = VeryExpensiveWorkThatReturnsImmutableArrayOfCustomModelContainingTheInfoWeNeedFromMetadata(...);
						s_map.Add(assembly.Identity, output);
					}

					foreach (var element in (ImmutableArray<CustomModelContainingTheInfoWeNeedFromMetadata>)output)
					{
						builder.Add(element);
					}
				}
			}
			return builder.ToImmutableArray();
		});

[CyrusNajmabadi]

Hahaha. No.

[jcouv]

Assigned to Fred and Cyrus to triage as area owners for syntax-related APIs.