Open chsienki opened 3 years ago
@chsienki Should we close out https://github.com/dotnet/roslyn/issues/48480?
Will this impact the way the compiler raises diagnostics for generated code? I can imagine there are a set of compiler checks we'd want to be ignored for generated code to simplify code-generators (eg: style analyzers) where there are others that we would want to be honored (obsolete, nullable annotations). cc @AaronRobinsonMSFT
Will this impact the way the compiler raises diagnostics for generated code?
Each analyzer can choose whether it needs to analyze generated code or not via the ConfigureGeneratedCodeAnalysis
method.
Today all analyzers that come with the SDK that are required for code correctness (for example security analyzers) look at generated code.
💠It seems desirable to continue requiring source generators to emit the // <auto-generated/>
header at the top of the file.
Looking at https://github.com/dotnet/runtime/pull/53275, the change is appending the .g
suffix to the file to indicate this is a generated file.
How many different ways are source generators supposed to mark their files as "generated"? So far I see:
// <auto-generated/>
header .g.cs
ConfigureGeneratedCodeAnalysis
What are the recommendations for dotnet/runtime
source generators should do to mark their code as "generated"?
@sharwell Is the following the appropriate way to add the comment?
SyntaxFactory.Comment("<auto-generated/>").ToString()
@AaronRobinsonMSFT SyntaxFactory.Comment
would be more for cases where you are generating a SyntaxTree
. For cases where you are generating a string, rather than use ToString()
like that line you could just add "// <auto-generated/>"
directly.
@chsienki can you fill out the API proposal template for this?
Added https://github.com/dotnet/roslyn/issues/56810 to track the API
We should add
GeneratedKind.SourceGenerator
and have any syntax trees added by a generator return this value.We should also update the original
bool
version of the property to report true for this value.