Reduce noisy C# compilation errors #2067
Open
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.
Description of Changes
When source generator processes code that misuses SpacetimeDB APIs, has wrong signatures, uses types incompatible with BSATN etc, it reports diagnostics but still emits new source code. In some cases, this improves autocomplete and diagnostics, since types and methods are still there even while code is not 100% valid yet, but in other cases the output code is so broken that .NET attempting to compile it will only produce even more noisy errors, which drown out the custom actionable diagnostic we emitted earlier in the pipeline.
This PR fixes couple of such cases by either fixing up or skipping particularly problematic entries during the codegen phase.
You can see the difference in the
crates/bindings-csharp/Codegen.Tests/fixtures/diag/snapshots/ExtraCompilationErrors.verified.txt
snapshot, which captures all the .NETcompilation errors that didn't come from our own source generator - there is a lot less noise after this PR.
API and ABI breaking changes
If this is an API or ABI breaking change, please apply the
corresponding GitHub label.
Expected complexity level and risk
1
How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.
This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.
Testing
dotnet test
snapshot tests