CC @eiriktsarpalis

@copilot is it possible to get the benchmark numbers showing the improvement?

@copilot is it possible to get the benchmark numbers showing the improvement?

The improvement is in build-time incrementality rather than runtime performance. The generator now avoids full re-runs when unrelated code changes (e.g., changing a method body that doesn't affect logger attributes).

To measure this, you'd need to:

1. Create a project with logger methods
2. Make an unrelated code change
3. Compare generator re-run behavior (before: re-runs on every compilation change, after: only re-runs when attributed syntax changes)

Roslyn's incremental generator infrastructure doesn't expose built-in metrics for this. The improvement is structural - by removing SemanticModel/ISymbol from the pipeline (which change on every compilation), the pipeline can now properly cache LoggerClass instances and only reprocess when the attributed methods actually change.

Would you like me to create a test project demonstrating the reduced re-runs, or would the structural fix verification be sufficient?

@copilot please fix the failure:

Discovering: Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests (method display = ClassAndMethod, method display options = None)
Discovered: Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests (found 78 of 79 test cases)
Starting: Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests (parallel test collections = on [2 threads], stop on fail = off)
Microsoft.Extensions.Logging.Generators.Tests.LoggerMessageGeneratorParserTests.MissingExceptionType [FAIL]
Assert.Single() Failure: The collection was empty
Stack Trace:
/_/src/libraries/Microsoft.Extensions.Logging.Abstractions/tests/Microsoft.Extensions.Logging.Generators.Tests/LoggerMessageGeneratorParserTests.cs(627,0): at Microsoft.Extensions.Logging.Generators.Tests.LoggerMessageGeneratorParserTests.MissingExceptionType()
--- End of stack trace from previous location ---
Finished: Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests

@copilot please fix the failure:

Discovering: Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests (method display = ClassAndMethod, method display options = None)
...

Fixed in bfe3713. The Roslyn 3.11 path had a combined null check that silently returned when System.Exception was unavailable, instead of reporting the MissingRequiredType diagnostic. Split the check to handle exceptionSymbol == null separately with context.ReportDiagnostic(Diagnostic.Create(DiagnosticDescriptors.MissingRequiredType, null, "System.Exception")), matching the original Parser.GetLogClasses behavior.

@copilot run the code review skill

@copilot run the code review skill

Code review completed. Here are the findings:

No ❌ errors found.

⚠️ warning — .Collect() defeats per-item incrementality for source output

Line 102 in LoggerMessageGenerator.Roslyn4.0.cs:

context.RegisterSourceOutput(loggerClasses.Collect(), static (spc, items) => Execute(items, spc));

Using .Collect() gathers all items into a single ImmutableArray, which means the Execute callback is invoked once with the entire collection whenever any item changes. This is necessary here because the generator produces a single combined output file (LoggerMessage.g.cs), but it does mean Execute re-runs and re-emits the entire file on any change to any attributed method. The incremental benefit comes from the transform step (which properly caches per-method via WithTrackingName), so the parsing work is properly skipped — but the emission step is not incremental. This matches the existing behavior (the old code also produced one combined file) and is an acceptable tradeoff. No action needed.

⚠️ warning — existingMethodKeys HashSet is rebuilt on every merge iteration

Lines 151-155: When merging partial class methods, a new HashSet<(string Name, int EventId)> is built from existingClass.Methods for each incoming LoggerClassSpec with the same key. In practice, partial class files are uncommon and have few methods, so this is fine. But if a future user has many partial files for a single class, it would be more efficient to maintain the set across merge iterations. Low priority, follow-up material.

💡 suggestion — BuildClassKey allocates a List<string> on every call

Lines 182-194: BuildClassKey creates a List<string>, reverses it, and joins it. Could use a StringBuilder or walk the chain in reverse to avoid the list allocation. Minor optimization for a cold path — follow-up at best.

💡 suggestion — LoggerClassSpec uses record with manual Equals/GetHashCode

The spec types are declared as sealed record but provide manual IEquatable<T> implementations. C# records auto-generate equality, so declaring custom Equals/GetHashCode overrides the record's default. This works correctly, but using sealed class instead of sealed record would be slightly less surprising since the record-generated equality is never used. This is cosmetic — no action needed.

✅ Verified correct:

• Spec records implement proper structural equality covering all fields including recursive ParentClass
• ImmutableEquatableArray<T> provides proper sequence equality for pipeline caching
• DiagnosticInfo with trimmed locations is consistent with the System.Text.Json generator pattern
• Partial class merging using HashSet<(string Name, int EventId)> handles the multi-file scenario correctly
• Diagnostic deduplication using HashSet<DiagnosticInfo> prevents duplicate reporting
• MissingRequiredType diagnostic is correctly reported in both Roslyn 3.11 and 4.0+ paths
• OrderBy(key, StringComparer.Ordinal) preserves deterministic output
• JsonSourceGenerator change is minimal and correct — just moves KnownTypeSymbols into the transform
• Roslyn 3.11 backward compatibility maintained
• Incremental tests properly use existingTree.Options for consistent language versions
• WithDiagnostics test files correctly use internal methods to avoid CS8795

@copilot run the code review skill

Code review completed. Found and fixed one issue in fdae4aa:

⚠️ hasStringCreate uses = instead of |= — In Execute, hasStringCreate = item.HasStringCreate overwrites on each item. While all items from the same compilation agree, |= is more correct-by-construction and costs nothing.

💡 TemplateMap ordering (follow-up, not blocking) — LoggerMethod.ToSpec() creates TemplateMap from Dictionary iteration order which isn't guaranteed by contract. ImmutableEquatableArray.Equals uses SequenceEqual, so different iteration orders could cause false cache misses. Sorting by key would make it deterministic. In practice this is unlikely to cause issues since the same method processed the same way produces the same order.

No errors found. All other aspects look correct:

• ✅ Spec records' Equals/GetHashCode are complete, covering all fields including recursive ParentClass
• ✅ Partial class merging via BuildClassKey + HashSet<(Name, EventId)> dedup is correct
• ✅ Diag() double-reporting is safe — _reportDiagnostic is null in Roslyn 4.0+ (only collects), non-null in Roslyn 3.11 (reports immediately)
• ✅ default return from transform correctly handled via item.Diagnostics is not null check
• ✅ Diagnostic deduplication via HashSet<DiagnosticInfo> prevents duplicates
• ✅ Deterministic output via OrderBy(key, StringComparer.Ordinal)
• ✅ MissingRequiredType diagnostic reported in both Roslyn 3.11 and 4.0+ paths
• ✅ JsonSourceGenerator change is minimal and correct
• ✅ Test parse options consistency is correct

@tarekgh do you have a roslyn tracking issue for the #pragma warning disable issue? we also hit it in the codeflow PR: dotnet/dotnet#4727 (comment)

We'll likely also need to file some breaking change notice since we document the pragma approach in https://learn.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/syslib1025

/cc @ericstj

I found #92509 and dotnet/roslyn#68291 which have more background on the issue

Right, #92509 is the tracking issue for different generators. I'll file the breaking change doc.

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2026-02-10 15:02:39

I filed the breaking change doc and linked it to this PR.

@akoeplinger thanks for pointing at the failures and sorry for the inconvenience. Please let me know if there is anything else I can help with.