This change set introduces the notions of registering compilation actions and code block actions into the diagnostics API. Compilation actions differ from compilation end actions in that they do not have access to per-compilation analyzer state and do not introduce action execution ordering constraints. Code block actions differ from code block end actions in that they do not have access to per-block analyzer state and do not introduce action execution ordering constraints.

This change set also removes RegisterXEndAction methods on contexts other than the corresponding StartXAnalysisContext types. This change is intended to guide analyzer authors towards introducing analyzer state with appropriate lifetime.

Some internal mechanism for the removed registration methods remains. This keeps the mechanism fully general and imposes a very marginal execution cost.

The specific API changes:
 -- Removal of AnalysisContext.RegisterCompilationEndAction. CompilationStartAnalysisContext.RegisterCompilationEndAction remains.
 -- Removal of AnalysisContext.RegisterCodeBlockEndAction and CompilationStartAnalysisContext.RegisterCodeBlockEndAction. CodeBlockStartAnalysisContext.RegisterCodeBlockEndAction remains.
 -- Introduction of AnalysisContext.RegisterCompilationAction.
 -- Introduction of AnalysisContext.RegisterCodeBlockAction and CompilationStartAnalysisContext.RegisterCodeBlockAction.
 -- Renaming of CompilationEndAnalysisContext to CompilationAnalysisContext.
 -- Renaming of CodeBlockEndAnalysisContext to CodeBlockAnalysisContext.

Add a CodeAnalysis diagnostic for detecting memory leaks in implementation of analyzers (DoNotStorePerCompilationDataOntoFields): Instance of a diagnostic analyzer might outlive the lifetime of compilation (when executed in the IDE). Hence, storing per-compilation data, such as symbols, into the fields of a diagnostic analyzer might cause stale compilations to stay alive and cause memory leaks. Instead, one should store this data on a separate type instantiatied in a compilation start action, registered using AnaylsisContext.RegisterCompilationStartActionName API. An instance of this type will be created per-compilation and it won't outlive compilation's lifetime, avoiding memory leaks.

Analyzer implementation: Analyzer tracks all field declarations within analyzer types (marked with DiagnosticAnalyzerAttribute) and flags if it's variable type declaration has any type syntax descendant that binds to a type implementing ISymbol or has Compilation in its type chain.

I have also added a few positive and negative tests for the diagnostic. (changeset 1394660)

I also found couple of bugs in the VB implementation of the analyzers during this exercise, which have been fixed. (changeset 1393711)

1) Type argument for "TLanguageKindEnum" type param to language specific register methods (RegisterSyntaxNodeAction, RegisterCodeBlockStartAction and RegisterCodeBlockStartAction) must be VB/C# SyntaxKind enum type.

2) Provide LocalizableString arguments for title and description parameters of DiagnosticDescriptor constructor. The rule is disabled by default, but enabled for all our analyzer projects. (changeset 1392911)

These projects (henceforth referred to as CodeAnalysis analyzers) are set of analyzers for the Roslyn APIs. As a start, I'm moving the few metaanalyzers that Manish wrote to this project. We will ship these analyzers with the roslyn nuget packages. So any rules we want to impose on consumers of Roslyn should go here. (changeset 1392712)

1) Analyzer has an expensive compilation end action: The compilation end actions registered on CompilationStartAnalysisContext can be executed only after all other actions registered on it have been executed on the entire compilation. This can hurt the typing performance when the analyzer is executed in the Visual Studio IDE. If the analysis done within your compilation end action is independent of analyses done in other actions registered on CompilationStartAnalysisContext, then consider registering this end action on AnalysisContext in Initialize method instead of registering it here. This should improve the IDE performance for your analyzer.

2) Recommend adding language support to diagnostic analyzer: If the analyzer supports just one of C#/VB languages, but the analyzer assembly doesn't reference either C# or VB CodeAnalysis assemblies, then the analyzer is pretty likely a language-agnostic analyzer and can support both languages. Consider either removing the argument to DiagnosticAnalyzerAttribute or adding a new DiagnosticAnalyzerAttribute for 'XXX' language support.

3) ReportDiagnostic invoked with an unsupported DiagnosticDescriptor: Only supported descriptors returned from DiagnosticAnalyzer.SupportedDiagnostics should be used for diagnostics reported by ReportDiagnostic. This is a common mistake when adding new rules to an existing analyzer, the diagnostic author might forget to update SupportedDiagnostics. (changeset 1391218)

Add Roslyn diagnostic analyzers for validating implementation of diagnostic analyzers (meta-analyzers)

1) MissingDiagnosticAnalyzerAttributeRule: Validate that non-abstract sub-type of DiagnosticAnalyzer has DiagnosticAnalyzerAttribute applied to it.

2) MissingKindArgumentRule: Ensure that at least one symbol kind/syntax kind argument is provided to RegisterSymbolAction/RegisterSyntaxNodeAction respectively.

3) UnsupportedSymbolKindArgumentRule: Ensure that only supported symbol kinds are registered with symbol analyzer actions.

4) ApplyDiagnosticAnalyzerAttributeFix: CodeFixProvider for Rule (1) to generate DiagnosticAnalyzer attribute(s). (changeset 1390936)