C# -IIncrementalGenerator를 적용한 Version 2 Source Generator 실습
지난 글에서,
C# -Version 1 Source Generator 실습
; https://www.sysnet.pe.kr/2/0/12985
Source Generator를 실습해 봤는데요, 마침, "dimohy" 님이 "
소스 생성기 만들기 - 1부 증분 생성기 만들기" 글을 번역해 주셨으니, 이참에 저도 그동안 미루고 미루던 C# 10의 특징 하나를,
C# 10 - (7) Source Generator V2 APIs (공식 문서, Source Generator V2 APIs)
; https://www.sysnet.pe.kr/2/0/12804
마무리 지어야겠습니다. ^^
Version 2 규약의 Source Generator의 프로젝트 구성은 V1과 비교해 달라진 점은 거의 없습니다. 단지, Microsoft.CodeAnalysis.CSharp 참조에 대한 버전만 올려주는 정도입니다.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<LangVersion>10.0</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.1.0" />
</ItemGroup>
</Project>
또한 소스 생성기가 구현해야 할 인터페이스도 아예 별도로 IIncrementalGenerator가 제공되므로,
public interface IIncrementalGenerator
{
void Initialize(IncrementalGeneratorInitializationContext context);
}
이를 사용해 다음과 같이 뼈대를 구성할 수 있습니다.
using Microsoft.CodeAnalysis;
namespace PropertySrcGenerator2
{
[Generator]
public class SourceGenerator : IIncrementalGenerator
{
public void Initialize(IncrementalGeneratorInitializationContext context)
{
}
}
}
특이하죠? ^^ 기존에는 ISourceGenerator 인터페이스가 Initialize/Execute 2단계의 동작을 지원했는데, IIncrementalGenerator에서는 1개로 더 간단해졌습니다.
하지만, V1에서도 그랬듯이 "[AutoProp]" 특성을 인식시켜야 하는 것은 Initialize에서도 유사한 구문을 제공하므로 다음과 같이 해결할 수 있습니다.
using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.Text;
using System.Text;
namespace PropertySrcGenerator2
{
[Generator]
public class SourceGenerator : IIncrementalGenerator
{
public const string AutoPropAttribute = @"
namespace System
{
[System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Struct)]
public class AutoPropAttribute : System.Attribute
{
}
}";
public void Initialize(IncrementalGeneratorInitializationContext context)
{
context.RegisterPostInitializationOutput((ctx) =>
{
ctx.AddSource("AutoPropAttribute.g.cs", SourceText.From(AutoPropAttribute, Encoding.UTF8));
});
}
}
}
반면, V1에서의 Execute 단계가 없으므로 이후의 소스 코드 생성 작업은 완전히 달라졌습니다. 하지만 V1에서 작성한 코드는 거의 그대로 재사용할 수 있습니다.
우선, V1에서의 ISyntaxReceiver와 같은 역할을 V2에서도 필요로 합니다. 단지 이 과정을 CreateSyntaxProvider 메서드를 이용해 다음과 같이 필터링 여부를 지정하는 코드로 바뀐 정도입니다.
IncrementalValuesProvider<ClassDeclarationSyntax> classDeclarations = context.SyntaxProvider
.CreateSyntaxProvider(
predicate: static (s, _) => IsSyntaxTargetForGeneration(s),
transform: static (ctx, _) => GetSemanticTargetForGeneration(ctx))
.Where(static m => m is not null)!;
"
소스 생성기 만들기 - 1부 증분 생성기 만들기"에서도 나오지만, predicate 인자로 넣은 IsSyntaxTargetForGeneration에서는 우리가 만들 Source Generator의 대상이 될 클래스를 필터링하기 위한 조건을 넣어두면 됩니다.
즉, predicate 인자는 Version 1의 경우 OnVisitSyntaxNode에서 했던 코드를 재사용하시면 됩니다. 하지만 OnVisitSyntaxNode의 경우 SemanticModel을 구할 수 없어 "AutoProp" 설정이 있는 것을 구분하기 위해 별로 우아하지 못한 방법을 사용했는데요, Version 2에서는 우선 "partial class"이면서 특성(Attribute)이 하나라도 있는 조건만 IsSyntaxTargetForGeneration에 지정하고,
static bool IsSyntaxTargetForGeneration(SyntaxNode node)
{
return node is ClassDeclarationSyntax m && m.AttributeLists.Count > 0;
}
이후 AutoProp 특성에 대한 지정 여부는 transform 인자로 전달한 GetSemanticTargetForGeneration에서 판정하도록 나눌 수 있습니다.
static ClassDeclarationSyntax? GetSemanticTargetForGeneration(GeneratorSyntaxContext context)
{
var classDeclarationSyntax = (ClassDeclarationSyntax)context.Node;
foreach (AttributeListSyntax attributeListSyntax in classDeclarationSyntax.AttributeLists)
{
foreach (AttributeSyntax attributeSyntax in attributeListSyntax.Attributes)
{
if (context.SemanticModel.GetSymbolInfo(attributeSyntax).Symbol is not IMethodSymbol attributeSymbol)
{
continue;
}
INamedTypeSymbol attributeContainingTypeSymbol = attributeSymbol.ContainingType;
string fullName = attributeContainingTypeSymbol.ToDisplayString();
if (fullName == "System.AutoPropAttribute")
{
return classDeclarationSyntax;
}
}
}
return null;
}
사실, transform의 경우 "
소스 생성기 만들기 - 1부 증분 생성기 만들기" 글에서도 "구문 토큰을 변환하는데 사용할 수 있지만 이 경우에는 술어 뒤에 추가 필터링을 제공하는 데만 사용"한다고 설명하고 있는 것처럼 아마도 처음 의도는 구문 변환이었을 것입니다. 하지만, 실제로 많은 source generator들의 특성상 대상 코드를 판정하기 위해 SemanticModel이 필요하므로 자연스럽게 필터링의 기능도 떠안게 된 것입니다.
즉, 원래는 prediacate에서 필터링이 잘 되었다면, transform 단계에서는... (사실 구문 토큰을 변환할 일이 그렇게 많지는 않을 듯하니) 이런 식으로 간단하게 작성할 수도 있었을 것입니다.
static ClassDeclarationSyntax? GetSemanticTargetForGeneration(GeneratorSyntaxContext context)
{
return context.Node;
}
어쨌든, transform에서도 필터링을 위해 대상이 아닌 경우 null을 반환하므로 CreateSyntaxProvider 반환 시 이에 대비해 Where 호출을 함께 호출해야 합니다.
IncrementalValuesProvider<ClassDeclarationSyntax> classDeclarations = context.SyntaxProvider
.CreateSyntaxProvider(
predicate: static (s, _) => IsSyntaxTargetForGeneration(s), // select class with attributes
transform: static (ctx, _) => GetSemanticTargetForGeneration(ctx)) // select class with the [AutoProp] attribute
.Where(static m => m is not null)!; // filter out attributed classes that we don't care about
필터링 조건을 만들었지만, 아직 이것이 컴파일러의 파이프라인 작업에 연결된 것은 아닙니다. 이를 위해서는 RegisterSourceOutput 메서드를 호출해야 하는데요, 이 과정에서 필터링 조건과 함께 비로소 V1의 Execute에 해당하는 델리게이트를 전달하게 됩니다. 단지, 이 과정에서 소스 코드 생성 과정에서 거의 필수로 참조하게 되는 Compilation 개체를 함께 묶는 것까지 우리가 처리를 해야 합니다.
IncrementalValueProvider<(Compilation, ImmutableArray<ClassDeclarationSyntax>)> compilationAndClass
= context.CompilationProvider.Combine(classDeclarations.Collect());
context.RegisterSourceOutput(compilationAndClass,)
static (spc, source) => Execute(source.Item1, source.Item2, spc));
사실, Compilation이 거의 필수이기 때문에 RegisterSourceOutput에 전달될 콜백 메서드의 signature로 고정시키지 않고 굳이 왜 외부에서 별도로 묶어 전달하게 했는지 잘 이해가 되지는 않습니다.
어쨌든, 위와 같이 Version 2에서는 (Version 1의) Execute 메서드를 우리가 직접 등록하는 식으로 바뀐 것을 제외하면, 이후의 코드 사용은 Version 1의 것을 거의 그대로 재사용할 수 있습니다.
static void Execute(Compilation compilation, ImmutableArray<ClassDeclarationSyntax> classes, SourceProductionContext context)
{
if (classes.IsDefaultOrEmpty)
{
return;
}
IEnumerable<ClassDeclarationSyntax> distinctClasses = classes.Distinct();
// 이후의 작업은 Version 1의 소스 코드를 그대로 가져온 것입니다.
foreach (var cls in distinctClasses)
{
List<AutoFieldInfo> fieldList = GetFieldList(compilation, cls);
if (fieldList.Count == 0)
{
continue;
}
string clsNamespace = GetNamespace(compilation, cls);
string src = GenerateSource(clsNamespace, cls.Identifier.ValueText, fieldList);
context.AddSource($"{cls.Identifier.ValueText}.g.cs", SourceText.From(src, Encoding.UTF8));
}
}
사실 개발자 입장에서는 Version 1과 Version 2의 구성에 크게 차이를 느낄 수는 없습니다. 단지, Version 2의 경우에는 CreateSyntaxProvider에 전달되는 필터링과 변환 작업을 파이프라인 작업에 참여할 수 있도록 Roslyn의 내부 구조를 변경한 듯하고, 그 각각의 과정(filtering/transform)에 대한 결과를 캐시해 재사용을 하면서 성능을 높인 것입니다. 가령, CreateSyntaxProvider의 predicate로 필터링된 반환 결과가 있을 때, 이후 소스 코드 편집 과정에서 predicate에 따른 반환 결과가 그대로라면 이후의 transform 작업은 하지 않는 식으로... 개선이 된 것입니다.
(이 글의 소스 생성기 프로젝트는
PropertySrcGenerator2이고, 그것을 적용한 예제 프로젝트는
PropertySrcSample2입니다.)
어쨌든 좋아졌다고 하니, ^^ 믿고 쓰면 될 텐데요, 단지 한 가지 단점이라면 Visual Studio 2022에서만 지원한다는 점입니다. 그리고 대상 프로젝트도 .NET 5 이후의 프로젝트에서만 가능합니다.
참고로, 몇 가지 적어보면, Source Generator로 생성되는 소스 코드는 기본적으로는 파일로 남지 않기 때문에 확인할 수 없습니다. 만약, 어떻게 생성되었는지 보고 싶다면, Visual Studio 편집기 내에서 관련 소스 코드를 사용하는 위치, 예를 들어 아래의 코드에서는,
using System;
internal class Program
{
static void Main(string[] args)
{
Book item = new Book("jst", 0);
Console.WriteLine(item.Writer);
}
}
[AutoProp]
public partial class Book
{
string writer = "";
decimal isbn = 0M;
}
Writer 속성을 사용한 코드에서 "Go To Definition(단축키: F12)"을 선택하면 그 순간 "%LOCALAPPDATA%\Temp\VSGeneratedDocuments\...[guid]..." 경로에 "[...].g.cs" 파일이 생성되면서 소스 코드가 열리게 됩니다.
또는, 아예 고정시켜 생성하는 것도 가능합니다. 이를 위해 csproj에 다음의 옵션을 추가하면 됩니다.
<PropertyGroup>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
</PropertyGroup>
그럼, 빌드 후 ".\obj\Debug\generated\PropertySrcGenerator2\PropertySrcGenerator2.SourceGenerator"와 같은 식의 경로 하위에 관련 "[...].g.cs" 파일들이 생성됩니다. 아마도 디버그 목적 이외에는 굳이 EmitCompilerGeneratedFiles 옵션을 사용할 필요는 없을 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]