Fix couple of analyzer bugs

[mavasani]

1. Fix DoNotDecreaseInheritedMemberVisibilityAnalyzer to match few more cases with binary FxCop
   Fixes CA2222 (DoNotDecreaseInheritedMemberVisibility) fires on members with resultant accessiblity private/internal #940
2. Fix TypeNamesShouldNotMatchNamespacesAnalyzer to not report analyze/report diagnostics on generated code.
   Fixes TypeNamesShouldNotMatchNamespaces (CA1724) reports on WinForms designer-generated code #949
   Seems like invoking analysisContext.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.Analyze), which should suppress all diagnostics on generated code, still allows the analyzer to report compilation end diagnostics on generated code. I'll file a separate bug on roslyn repo to fix the driver.

[mavasani]

Tagging @dotnet/roslyn-analysis for review

[srivatsn]

👍

[bkoelman]

@mavasani Did you already file a separate bug on roslyn repo to fix the driver?

I have looked around in the source of AnalyzerDriver / AnalyzerExecutor and believe there is no easy way to get this working.

SymbolAnalysisContext.ReportDiagnostic() does not receive the symbol it applies to. But it is always executed as a result of analyzing a known symbol (the one in SymbolAnalysisContext object). That known symbol is then checked for whether it comes from generated code, not the actual symbol on which a diagnostic is reported.

CompilationAnalysisContext.ReportDiagnostic() also does not receive the symbol it applies to, only the (first?) location (which is optional). As it may report anything from the compilation, it's not clear which source symbol/node/operation/... should be checked for whether it comes from generated code.

So I don't see an obvious way for the driver/executor to determine whether a symbol, syntax node, tree or operation comes from generated code in the Compilation End analysis.

[mavasani]

@bkoelman I'll file it now. Note that we do the generated code filtering for reported diagnostics based on its primary location, not based on what context it was reported. See this method: http://source.roslyn.io/#Microsoft.CodeAnalysis/DiagnosticAnalyzer/AnalyzerDriver.cs,303.

We just need to fix this method to add this if check to do this filtering for compilation diagnostics, we seem to be doing it only for non-compilation diagnostics.

[mavasani]

Opened dotnet/roslyn#11217

[bkoelman]

@mavasani Yes you are correct. I see now how I got on the wrong track by looking at isGeneratedCode parameter. The primary location is actually used for source.