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)

Implements a new approach to generating unique synthesized member names (see also the attached email).

     1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique.
     2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead.
     3) Removes GenerateTempNumber from TypeCompiationState. Combination of method ordinal and other indices is used to make generated names unique:
     - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name (it;'s simple named "c<>").
     - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method).
     - The same for fields caching lambdas.
     - Dynamic site containers - no longer include method name in the type name, instead method ordinal is used.

     4) Expression compiler - rename generated type to "<>x" to avoid confusion with "<>c" static display class.
     5) Avoid replacing "." with "_" in member names, other than type names. While displaying stack frames the EE extracts method name from synthesized lambdas method names and displays it. Thus we were displaying "I_F" instead of "I.F" for explicitly implemented methods.
      In type names replace "." with "-". Replacing with "_" lead to duplicate type names in emitted assembly (2 iterator methods with names "I_F" and "I.F" - explicitly implemented iface method). (changeset 1390962)

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)

The vast majority of this came from ADGreen (thanks Anthony!), which in turn had a great deal ported from the work I'd done in C#.  At this point, I'm not sure *who* wrote this code. It's shelvesets all the way down.

* Automatic brace completion
* Formatting
* Completion list
* Brace matching
* Classification (changeset 1390884)

Also fixes bug 1097058 by removing the suppressions for now fixed RS0013. (changeset 1390773)

Disable a missed keepalive test and mark it with the same workitem to investigate keepalive test reliability (CS 1095079). (changeset 1390720)

This matches the folder mapping of the git repository and makes it easier
to do mapping to Codeplex/Git. (changeset 1390665)

***NO_CI***
 (changeset 1390660)

C#: GetAndValidateConstantValue – Adjust error recovery code to avoid unintentional suppression of expected diagnostic.
***NO_CI***
 (changeset 1390636)

Fix for bug 1088032: We need to move all our analyzers to use localizable strings for title and description.

Update FxCop and Roslyn analyzers in Roslyn.sln to use the newly added DiagnosticDescriptor constructor that takes LocalizableString for Title, MessageFormat and Description. (changeset 1390465)

The renamed files from my previous somehow didn't have the edits but just had the rename checked in. Checking in the edits as well. (changeset 1390443)

The IDE uses four public APIs from the compiler layer for doing running analyzers in the IDE:

1. A bunch of static methods on AnalyzerDriver called Execute*Actions which take a type called AnalyzerActions which should be an implementation detail. So first change is to create a shared project called AnalyzerDriver that is referenced by CodeAnalysis and Features layers. I've split out these statics into a type called AnalyzerDriverHelper and made that internal. One challenge in doing this is that these methods create instances of Contexts and currently their constructors are internal. I've added constructors where possible and for some contexts that were taking Scopes, I've changed them to be abstract base classes and eliminated the scopes altogether. As part of pulling these methods, I needed some collections like ArrayBuilder, PooledDictionary etc and created another shared project called SharedCollections and put them there.

2. SemanticModel.GetDeclarationsInSpan - this is used by the IDE to calculate the declarations on which to run analyzers. This has also been pulled into the shared project and the API on semantic model made internal. We need a mechanism for branching into C#\VB implementations on both sides. Hence, the compiler API on semanticmodel still exists and is internal. On the features side, I have a language service, that branches into C#\VB and the implementation simply calls into the shared code.

3,4. AnalyzerDriver.GetEffectiveDiagnsotics and AnalyzerDriver.IsAnalyzerSuppressed() are two APIs about filtering that the IDE uses. There are legitimate scenarios for both of them being public APIs even if we make the IDE simply ask the compiler to run its analyzers. For eg: the IDE will need to run Document analyzers and the compiler can never run them. It needs to filter the results after that. Filtering requires pragma state and suppressmessage etc which are compiler'y things. The plan here is to move these APIs to a type called CompilationWithAnalyzers that John is creating to replace the AnalyzerDriver.GetAnalyzerdiagnostics() method. Once that happens, we can make AnalyzerDriver fully internal. This change doesn't touch those methods.

The shared code needed to access some resources. So I've created a type called AnalyzerDriverResources in both the Codeanalysis and features projects and they redirect to the appropriate resources.
 (changeset 1390439)

There are two scenarios which could be better. First, if the client hits an unrecoverable error we need as much information as possible to debug it. The solution to this is stop catching our fatal exceptions and instead let them bubble out of the process, much like our exception fail fast.

Second, if the problem is that the compiler itself has crashed, we should report that error to the user and tell them where they can get more information about the crash (i.e., the event log). (changeset 1390397)

Ensure that GetConstantValueDiagnostics API never returns default ImmutableArray to avoid NullReferenceException while trying to foreach over it.
***NO_CI***
 (changeset 1390350)

1) Add VB and C# compiler tests to verify that all configurable compiler diagnostics (non-errors) that show up in the ruleset editor have a non-null and non-empty Title and Category.
2) Commented out some more unused diagnostic IDs in both compilers that were found through these tests.
3) Add title resource strings for hidden and info compiler diagnostics. These are configurable and show up in the ruleset editor. (changeset 1390346)

This fixes a couple of minor issues with AnalyzerDriver.

1. The compilation process was always shutting down with two first
chance exceptions.   The code would unconditionally loop an await
DequeueAsync calls which results in a TaskCanceledException when the
CompilationEventQueue is completed.  That exception was then rethrown to
the calling method.

This is not wrong but it significantly hinders the debugging experience
in Visual Studio (exceptions result in dialogs + pauses).  And the
second throw essentially amounts to using exceptions as control flow.

I changed the code to stop looping when there was no potential for
future data from the CompilationEventQueue.  If the queue is completed
and has zero entries then no more data will ever be added and calling
DequeueAsync is wasted processing.  This is the normal shut down
sequence for the compiler.

2. The exception handling code covered two methods: DequeueAsync and
ProcessEventAsync.  It assumed that TaskCanceledException always came
from DequeueAsync.  If ProcessEventAsync ever threw a
TaskCanceledException the event loop logic would be incorrect.  Changed
the handling to be separate for each call.
***NO_CI***
 (changeset 1390329)

Fix RS0013 (Do not access property Descriptor on Diagnostic type within compilers layer) to not be reported within Diagnostic type itself. (changeset 1390290)

Initial compiler support for VB string interpolation. Does not include target typing or any IDE support. (changeset 1390282)

While inspecting AnalyzerDriver last night I noticed that it would potentially deadlock if these methods were called on one of the event queues.  Looking through our code base I noticed these methods were never invoked and after discussion with Neal and Sri decided to remove them vs. trying to account for their usage in AnalyzerDriver. (changeset 1390239)

This change implements the following rule from section 6.2.3 (Explicit Nullable Conversions).  In particular the following section.

     - If the nullable conversion is from S to T?, the conversion is evaluated as the underlying conversion from S to T followed by a wrapping from T to T?

     This rule is what is responsible for keeping expressions like the following an error:

     (int?)double.MaxValue

     The code generation changes in the Emit suites occurred because the compiler is retains the constants produced from the S -> T conversion (this mirrors the native compiler behavior).
 (changeset 1389914)

 (changeset 1389865)

     We now look for directives in the using statements and attempt to place the new using outside if possible.
***NO_CI***
 (changeset 1389840)

* Remove the "defaultEncoding" field from document state
* Set the encoding for SourceText's backed from ITextSnapshot from the ITextDocument if possible, instead of blindly using UTF-8.
* When saving files in the MSBuildWorkspace, if the encoding isn't set (say, because a tree-rewrite happens), load the original on disk text and re-use it's encoding, instead of blindly re-writing it to UTF-8.
 (changeset 1389834)

This is necessary to correctly reject invalid assembly names in InternalsVisibleTo and to match the native compiler. (changeset 1389827)

Add GetBaseAndInterfaceTypes
Add AddBaseType
Add AddInterfaceType

Also simplified some SyntaxEditor extensions. (changeset 1389749)

We're supposed to be picking up this assembly from a NuGet package, but one project still has a project-to-project reference instead. This means different projects are building against different versions of the assembly, and this can cause the build to fail depending on the order in which projects are handled.

Also, a couple of projects had references to two different versions of the NuGet. At the very least the assembly would show up twice in Solution Explorer (once as a resolved reference, and once as an unresolved reference) but probably also caused build issues on a system with both versions present in the packages directory. (changeset 1389738)

Added SyntaxGenerator.InsertNodesAfter
Added SyntaxNode.WithTriviaFrom
Added SyntaxNode.WithoutTrivia
Added SyntaxToken.WithTriviaFrom (changeset 1389664)

A few small tweaks in the implementation of IsKind and Kind that make them more efficient and avoid reference comparison with a string literal. (changeset 1389634)

C# MethodTypeInferrer.Fix: Do not consider dynamic type convertible to any other type in order to duplicate native compiler behavior.
***NO_CI***
 (changeset 1389606)