ref: rename SourceGenerators to Compiler-Extensions

[Flash0ver]

Rename

-Sentry.SourceGenerators
+Sentry.Compiler.Extensions
-Sentry.SourceGenerators.Tests
+Sentry.Compiler.Extensions.Tests

As discussed here: #4321 (comment)

I noticed that packages 6.0.0-preview.1-prerelease and 6.0.0-preview.2-prerelease are missing the compiler extensions under /analyzers/dotnet/cs/Sentry.SourceGenerators.dll.
I got a fix for that almost ready in a personal project, that I'll apply to Sentry version6 branch tomorrow.
While noticing the problem, I thought: might as well do the rename now ... as I am not 100 % certain it's not a breaking change for some scenarios ... so I was thinking about doing this for v6.

---

#skip-changelog

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (version6@19a8c1a). Learn more about missing BASE report.

Additional details and impacted files

@@             Coverage Diff             @@
##             version6    #4702   +/-   ##
===========================================
  Coverage            ?   73.19%           
===========================================
  Files               ?      480           
  Lines               ?    17422           
  Branches            ?     3437           
===========================================
  Hits                ?    12752           
  Misses              ?     3820           
  Partials            ?      850           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Flash0ver]

@sentry review

[sentry]

The code uses StringBuilder class (sb.Append, sb.AppendLine) but there is no using System.Text; statement at the top of the file. This will cause a compilation error. Add the missing using statement.
_{Severity: CRITICAL}

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/Sentry.Compiler.Extensions/BuildPropertySourceGenerator.cs#L1-L3

Potential issue: The code uses `StringBuilder` class (sb.Append, sb.AppendLine) but
there is no `using System.Text;` statement at the top of the file. This will cause a
compilation error. Add the missing using statement.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[Flash0ver]

Short: Already included via https://github.com/getsentry/sentry-dotnet/blob/d1aa0f1f902df371df95977fa2ddca64b8fa8d22/GlobalUsings.cs

[Flash0ver]

Long: making Semantic decisions just off of Syntax is pretty much impossible these days in .NET:

• C# 10.0 Global Using Directives
  • can be declared in C# per project, e.g. global using System.Text;
  • can be declared in MSBuild per project, e.g. <Using Include="System.Text" />
    • and then there is also the opposite <Using Remove="System.Text" />
  • additionally, both a C# "GlobalUsings.cs" file, as well as MSBuild <Using/> properties can be imported to multiple projects explicitly via <Import Project=".." /> or implicitly via Directory.Build.props or Directory.Build.targets
• StringBuilder != StringBuilder
  • users can declare their own custom StringBuilder type in a different namespace ... e.g. a Sentry.StringBuilder
  • without a fully-qualified-identifier in the source text, a type may origin from any imported namespace ... although there will be compiler errors for ambiguities, when a non-qualified typename occurs in multiple namespaces that have been imported
• Source Generators and Interceptors
  • with C# Interceptors available, by just looking at C# Syntax we don't definitively know whether the mentioned methods Append and AppendLine are actually bound to the instance members of System.Text.StringBuilder, or intercepted (at compile-time) by another ordinary method
• Extension Members
  • not really applicable to this comment, but further highlighting that without the "Semantic Model" (by only inspecting the C# Syntax Tree) we can't definitively say which types and members the compiler is binding to ... unless it's one of the predefined C# types like int, string, and so on
• Implicit Global Usings
  • also not applicable to this comment, but
  • with the MSBuild property <ImplicitUsings>enable</ImplicitUsings>, depending on the Project SDK (e.g. <Project Sdk="Microsoft.NET.Sdk">), a predefined set of Global Usings are automatically emitted

---

Regarding this comment:
System.Text actually is imported ... via:

• BuildPropertySourceGenerator.cs is in Project Sentry.Compiler.Extensions
• Project Sentry.Compiler.Extensions implicitly imports the parent directory's Directory.Build.props
  • https://github.com/getsentry/sentry-dotnet/blob/main/src/Directory.Build.props
• this /src/Directory.Build.props file explicitly imports the parent directory's Directory.Build.props
  • https://github.com/getsentry/sentry-dotnet/blob/main/Directory.Build.props
• this /Directory.Build.props file adds a GlobalUsings.cs file to be compiled

  • sentry-dotnet/Directory.Build.props

    Lines 79 to 80 in 1ddfa66

    	<ItemGroup Condition="!$(MSBuildProjectName.Contains('Samples'))">
    	<Compile Include="$(MSBuildThisFileDirectory)GlobalUsings.cs" />

• this /GlobalUsings.cs includes the Global Using

  • sentry-dotnet/GlobalUsings.cs

    Line 30 in 1ddfa66

    global using System.Text;

[alexsohn1126]

Is there a reason why we are renaming these from SourceGenerators? What parts about it make it more a compiler extension than a source generator?

[Flash0ver]

Is there a reason why we are renaming these from SourceGenerators? What parts about it make it more a compiler extension than a source generator?

A Source-Generator is a Compiler-Extension.
There are more Compiler-Extensions that can be shipped in NuGet packages:

• DiagnosticAnalyzer
• DiagnosticSuppressor
• ISourceGenerator
• IIncrementalGenerator
• CodeFixProvider
• RefactoringProvider

and I believe you can also ship a "Completion-Provider" (as in the IDEs auto-completion lists).
This, and the latter two from the list, require "Workspaces APIs" (i.e. Microsoft.CodeAnalysis.CSharp|VisualBasic.Workspaces.
Where the former four from the list do not require the "Workspaces APIs" (i.e. only Microsoft.CodeAnalysis.CSharp|VisualBasic.

It's best practice to separate Compiler-Extensions that do require the Workspaces APIs from the ones that do not. Because depending on the Host (the Roslyn Compiler is "just" a library) the Workspaces APIs may or may not have been loaded.
Conversely, it's OK to group/join Compiler-Extensions by their dependencies.

Sentry.SourceGenerators indicates that it only includes ISourceGenerator and IIncrementalGenerator implementations. We thought we needed to ship a DiagnosticSuppressor for #4627, but would have not liked to have another project (like Sentry.DiagnosticSuppressors). We also had discussions of adding DiagnosticAnalyzer in other issues, and again don't want to have yet another project (e.g. Sentry.DiagnosticAnalyzers).

So we want to ship up to two Roslyn-Components/DLLs that include Compiler-Extension: the ones that do not require the Workspaces APIs, and the ones that do.
And therefore we wanted to change the very specific name of Sentry.SourceGenerators to something more generic, to allow us to ship more Compiler-Extensions in the future easily with the already available infrastructure.

Our preference was to include something like "Compiler" and "Extension" in the name, since these are the documented terms for these Roslyn Components:

• see RS1038
• see RS1041

So we could go with

• Sentry.Compiler.Extensions for "Compiler-Extensions" that do not require the Workspaces APIs
• and something like Sentry.Compiler.Extensions.Actions or Sentry.Compiler.Extensions.CodeActions for the ones that do require the Workspaces APIs (which we currently don't have)

[alexsohn1126]

Thanks for the explanation! Love learning more about .NET 💯