AutoGenerated: Consider using the build in `IsGenerated` properties of the analysis contexts

[martin-strecker-sonarsource]

Detecting generated code is an essential building block for our analyzers. At the moment, we use a heuristic on the syntax-tree level in the GeneratedCodeRecognizer. This has some problems:

• Some attributes, we use for detection [DebuggerNonUserCode] can be applied at method level. We consider the whole tree as auto-generated if such an attribute is present at the method level. This causes FNs.
• Each registered action invocation calls the "AutoGenerated" logic and is, therefore, on the hot path. We cache on the syntax tree, but the factory method is still executed multiple times per tree until it is stored in the cache (the factory is lock-free).

In https://github.com/dotnet/roslyn/issues/7578 from September 2022, IsGeneratedCode was added to all ..AnalyzisContext types by the Roslyn team:

• SymbolStartAnalysisContext
• CodeblockAnalysisContext
• CodeblockStartSnalysisContext
• OperationAnalysisContext
• OperationBlockAnalysisContext
• SemanticmodelAnalysisContext
• SymbolAnalysisContext
• SyntaxNodeAnalysisContext
• SyntaxTreeAnalysisContext

We should consider lighting up these properties and using them if the compiler supports them. We need to see how Roslyn recognizes the AutoGenerated code, how it differs from outer logic, and what to do about the differences.

Related links:

• https://github.com/dotnet/roslyn/issues/7578
• Must read (also discusses Razor-specific problems): https://github.com/dotnet/roslyn/issues/39758
• AnalysisContext.ConfigureGeneratedCodeAnalysis

[pavel-mikula-sonarsource]

There's a related Trello card about this area: https://trello.com/c/Nc2mpdjz/180-read-generatedcodeanalysisflags-from-roslyn-for-generated-code-analysis

[costin-zaharia-sonarsource]

Related: #5461