Ensure that SemanticModel binds with an IncrementalBinder if result of the binding is added to the cache.

update comment and add unit test for VS workspace diagnostic analyzer provider service

Consume new async light bulb APIs from VS platform. 

This makes the light bulb preview pane render asynchronously so that expensive previews don't block the UI thread.

Ensure that SemanticModel binds with an IncrementalBinder if result of the binding is added to the cache.

Fixes #1504.

Add handling of ArrowExpressionClauseSyntax nodes to LocalBinderFactory.

In cases where primary document from which the rename tracking fix was triggered doesn't have any changes (aside from the rename which is already in the buffer), we would end up offering no preview. This change ensures that we will go on and return preview for some other document that did have changes in such cases.

Fix perf issue that was causing the tagger that's used in preview pane to unnecessarily peg CPU on UI thread. We were unnecessary cycling through all documents in a project when we only needed to process a single document.

Consume new async light bulb APIs. This makes the light bulb preview pane render asynchronously so that expensive previews don't block the UI thread.

Upgrade the BCL NuGet packages to RC versions.

Upgrades System.Collections.Immutable to 1.1.34-rc and System.Reflection.Metadata to 1.0.19-rc.

Upgrades System.Collections.Immutable to 1.1.34-rc and
System.Reflection.Metadata to 1.0.19-rc.

Add support for await expressions to SyntaxGenerator

Update the interface definitions for IVsTelemetry.

Fix issues in the compiler related to rewriting existing files (port from preview)

End Construct should look at the context to determine the generated statement

Ensure that partially assigned structures are properly hoisted by async rewriter.

Fixes #971.

Use VB core on our build tools

Update our compiler and diagnostics toolset to the latest signed build.
Also disable a unit test that fails with new toolset.

Also disable a unit test that fails with new toolset.

Ensure that speculation analyzer catches replacements which introduces an error type in any of the ancestor expressions.

Fixes internal bug 1086771

don't leak exception when path contains illegal path char

original watson bug is fixed by using extension manager when we do info ...

TryCombine should never throw exception.

Analyzer driver performance improvements to improve command line build throughput with analyzers.

These changes bring down the self-build of Roslyn.sln with Roslyn analyzers from 2x of the core build time (build with no analyzers) to ~1.15x on my box.

1.Parallelize compilation event processing: Currently, a single thread processes all compilation events. This is the primary bottleneck for 2x build time with analyzers enabled. However, now that multiple threads process compilation events and execute analyzers, we need to guard against actions running concurrently for the same analyzer instance via a lock. This is accomplished via creating unique gate objects per analyzer instance and locking on them. Deadlock is not possible as these are stored on a private map of the core AnalyzerExecutor, and analyzer callbacks cannot call back into the AnalyzerDriver.


2.Execute syntax node actions for every symbol declared event sequentially: Current approach executes node actions in parallel for different analyzers (though each analyzer's actions are always executed sequentially). Invariably, these action callbacks on different analyzers share the same semantic model, leading to lot of contention on bound node cache accesses, hurting the overall performance. Switching this to completely sequential execution model for each symbol declared event, along with optimization (1) improves the overall performance. There is scope to still fine tune perf here by executing actions with distinct {Analyzer, SemanticModel} tuple in parallel, but I'll leave that for a separate attempt.

These changes bring down the self-build of Roslyn.sln with Roslyn analyzers from 2x of the core build time (build with no analyzers) to ~1.15x on my box.

1) Parallelize compilation event processing: Currently, a single thread processes all compilation events. This is the primary bottleneck for 2x build time with analyzers enabled. However, now that multiple threads process compilation events and execute analyzers, we need to guard against actions running concurrently for the same analyzer instance via a lock. This is accomplished via creating unique gate objects per analyzer instance and locking on them. Deadlock is not possible as these are stored on a private map of the core AnalyzerExecutor, and analyzer callbacks cannot call back into the AnalyzerDriver.

2) Execute syntax node actions for every symbol declared event sequentially: Current approach executes node actions in parallel for different analyzers (though each analyzer's actions are always executed sequentially). Invariably, these action callbacks on different analyzers share the same semantic model, leading to lot of contention on bound node cache accesses, hurting the overall performance. Switching this to completely sequential execution model for each symbol declared event, along with optimization (1) improves the overall performance. There is scope to still fine tune perf here by executing actions with distinct {Analyzer, SemanticModel} tuple in parallel, but I'll leave that for a separate attempt.

Let Jenkins specify a custom mono path

EE: Ignore accessibility in ExpressionLambdaRewriter

Fixes #1618

EE: "Static members", etc. should not inherit Access, StorageType, TypeModifierFlags from parent item