Add render-tree-builder-call baseline for component codegen tests - #84162
Merged
chsienki merged 2 commits intoJun 17, 2026
Conversation
Component codegen tests pin the emitted C# against `.codegen.cs` baselines. That text shifts whenever the generated members are reorganized -- for example when a component is split across multiple partial documents -- so a `.codegen.cs` diff can be large even when the component renders identically, and on its own is a poor signal for whether the render behavior changed. Add a baseline that projects the generated C# down to the render operations it performs. `BuilderCallDumper` parses the emitted code and extracts every `__builder.<op>(sequence, ...)` call -- OpenElement, AddAttribute, AddContent, OpenComponent, AddComponentParameter, ... -- and writes them ordered by sequence number to a `.builder.txt` baseline next to the existing codegen baselines. Calls without a sequence number (CloseElement, SetKey, AddNamedEvent) are positional bookkeeping and are omitted. The sequence number is the compile-time, source-position identity Razor assigns each render operation. Ordering by it yields a projection that is invariant under cosmetic reorganization of the generated members -- which partial half a member lands in, line-pragma layout, method extraction, whitespace -- yet still trips on a real change: a different element name, a dropped attribute, a renumbered fragment. The projection is computed from the generated source text, so it is deterministic and runs on both net472 and net10.0. `ComponentCodeGenerationTestBase` runs the check from its `CompileToAssembly` shadow, so every test calling `CompileToAssembly(generated)` picks it up with no per-test change. A test can opt out with `assertBuilderBaseline: false`. Components that emit no builder calls get no baseline. Generate baselines with: #define GENERATE_BASELINES in src/Razor/src/Shared/Microsoft.AspNetCore.Razor.Test.Common/GenerateBaselines.cs dotnet test src/Razor/src/Compiler/Microsoft.AspNetCore.Razor.Language/test --filter FullyQualifiedName~ComponentCodeGenerationTestBase Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
davidwengier
approved these changes
Jun 17, 2026
chsienki
enabled auto-merge (squash)
June 17, 2026 02:23
CSharpSyntaxTree.ParseText(string) is banned by RS0030 in this repo; the SourceText overload is the approved entry point. Also drop the runtime-frame comparison framing from the type's <remarks> so it describes only what the projection is. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Component codegen tests pin the emitted C# against
.codegen.csbaselines. That text shifts whenever the generated members are reorganized -- for example when a component is split across multiple partial documents -- so a.codegen.csdiff can be large even when the component renders identically, and on its own is a poor signal for whether the render behavior changed.This adds a baseline that projects the generated C# down to the render operations it performs.
BuilderCallDumperparses the emitted code and extracts every__builder.<op>(sequence, ...)call --OpenElement,AddAttribute,AddContent,OpenComponent,AddComponentParameter, ... -- and writes them ordered by sequence number to a.builder.txtbaseline next to the existing codegen baselines. Calls without a sequence number (CloseElement,SetKey,AddNamedEvent) are positional bookkeeping and are omitted.The sequence number is the compile-time, source-position identity Razor assigns each render operation. Ordering by it yields a projection that is invariant under cosmetic reorganization of the generated members -- which partial half a member lands in, line-pragma layout, method extraction, whitespace -- yet still trips on a real change: a different element name, a dropped attribute, a renumbered fragment. The projection is computed from the generated source text, so it is deterministic and runs on both
net472andnet10.0.ComponentCodeGenerationTestBaseruns the check from itsCompileToAssemblyshadow, so every test callingCompileToAssembly(generated)picks it up with no per-test change. A test can opt out withassertBuilderBaseline: false. Components that emit no builder calls get no baseline.No production code changes -- this is test infrastructure only.
Microsoft Reviewers: Open in CodeFlow