SourceGenerator diagnostics not appearing in error list #49664
Comments
Dotnet-GitSync-Bot
added
Area-Compilers
untriaged
jasonmalinowski
removed
the
untriaged
|
I am also experiencing this issue while trying to create a Source Generator. The highlighted line in this source window corresponds to one of the errors listed below. My branch is here, if that helps: https://github.com/ReubenBond/orleans/tree/feature/source-generator, and the source generator is here: https://github.com/ReubenBond/orleans/blob/feature/source-generator/src/Orleans.CodeGenerator/OrleansSourceGenerator.cs |
jasonmalinowski
changed the title
|
Just to confirm and bump up - we experience this issue a lot (VS 2022) when trying to build a Blazor project after indirectly introducing some errors in razor files. By indirectly, I mean making some refactorings inside the model/service layer that are not properly reflected in the razor files (while the erroneous Blazor components remain closed in the editor). It causes false positives scenario - the error list is empty while the build is failing for no obvious reason. The only fallback solution is to try building the project from CLI and look for the actual errors throughout the console output. Significantly affects the quality of life, to be honest. |
|
Just adding my own voice here as this is impacting warnings in Razor files (.cshtml and .razor) since the Razor compiler switched to using a source generator in .NET 6. Nullable warnings in Razor files do not show up in the VS Error List unless the file is open in the editor. I often don't see the warning until the CI build fails 😢 |
|
Agreed this is a pretty big quality of life issue for razor files. Not being able to trust the error list is disconcerting. |
This adds support for showing generator-produced diagnostics in the error list. The implementation generally follows how we handle diagnostics for files that we were unable to read in the IDE -- there is a placeholder analyzer that represents the diagnostics in our various state sets. The one interesting thing this changes a bit is our handling of the full-solution analysis flag. While testing this (and seeing how the file load diagnostics worked), I noticed that we had an early bail in "analyze project" that meant two things: Unless you had FSA on, there was no way to actually view file load diagnostics; this seemed odd since you then might have diagnostics in your error list about missing types, but you wouldn't see the root problem. If you turned FSA back off, nothing would ever run to make the FSA-produced diagnostics go away, short of you manually opening files or something. Thus I am changing the FSA handling a bit: if FSA is off, rather than skip everything we are only skipping the analysis now; this ensures that we are clearing out old/stale diagnostics, and we have an opportunity to still show the generator and file load diagnostics that we may have on hand. We only still produce those for other files (or things in the dependency graph) for files that are open though -- the key here is unlike regular diagnostics, these are diagnostics we know that came from the very production of the compilation itself. If the file is open, we're already going to have compilations being created for it (indeed, at least for open file diagnostics!), so we're not creating any extra work than we already had. Fixes dotnet#49664 Fixes dotnet#58435 Fixes dotnet#54098
Version Used: visual studio 16.8.2 and 16.9 preview 1
Intellisense shows members created by the source generator, and you can navigate to the generated code. Building displays the diagnostics. However the diagnostics don't appear in the diagnostics tab when set to show "Intellisense only" diagnostics.
Steps to Reproduce:
|marks location of caret)public class Container : IContainer<int> { int x => _| }it will display_disposedin the completion list._disposedinpublic class Container : IContainer<int> { int x => _disposed; }The text was updated successfully, but these errors were encountered: