Validate generator diagnostics after incremental updates - #82113
Conversation
| string parameterName, | ||
| bool initialization = false) | ||
| { | ||
| _output.WriteLine(diagnostic.ToString()); |
There was a problem hiding this comment.
It was useful to see the stacktrace that customers will see even though we don't validate it in the test obviously
Co-authored-by: Cyrus Najmabadi <cyrus.najmabadi@gmail.com>
Also should make it work under non-English locales.
|
@dotnet/roslyn-compiler for another review, thanks |
| #endif | ||
| _output.WriteLine(diagnostic.ToString()); | ||
|
|
||
| var expectedMessage = new ArgumentException(message: message, paramName: parameterName).Message; |
|
If this is merged, what would the behavior for the original bug be with the new code? The generator keeps running but there are some yellow bars, generator stops running, etc ...? |
|
It looks like the generator keeps running in either case (and so the crash is being reported repeatedly).
|
|
@dotnet/roslyn-compiler for another review, thanks (not sure if sign off from Cyrus + Chris counts as two compiler reviews) |
|
@RikkiGibson @dotnet/roslyn-compiler for another review, thanks |
|
@dotnet/roslyn-compiler for another review, thanks |
|
@RikkiGibson @dotnet/roslyn-compiler for another review, thanks |
|
@dotnet/roslyn-compiler for another review, thanks |
* test: pin diagnostic-location safety across incremental updates Mirrors the bug class fixed by dotnet/roslyn#82113 (issue #82032), from the consumer side. A generator diagnostic whose location was captured against a longer tree must not survive a shrinking incremental edit as an out-of-range span. Our DiagnosticInfo/LocationInfo reconstruct an external-file location (never source-tree-bound), so the driver never range-validates it and a shrink can neither crash the generator nor report a stale span. The test drives CSharpGeneratorDriver across a shrinking ReplaceSyntaxTree edit and asserts the re-reported AL0301 location is external (IsInSource == false) and in range of the new tree, with no generator-failure diagnostic. It fails if LocationInfo.ToLocation() ever regresses to a source-tree-bound location. Bonus: extract a public GeneratorTestHelper.CreateCompilation primitive (reused by RunGenerator) so tests can drive the driver directly for incremental scenarios, and declare the now-direct Microsoft.CodeAnalysis.CSharp dependency on the DU test project. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: execute tests in CI so publish is gated on behavior, not just compile The build job compiled the test projects but never ran them, so a runtime regression could pass CI and auto-publish to nuget.org. Add a Test step after Build on both ubuntu + windows. publish `needs: build`, so a failing test now fails the job and blocks the release — closing the gap without touching the fleet-managed branch protection. CrefRegression.Tests stays a compile-only guard covered by Build (it has no test-platform reference). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6 participants
Fixes #82032.