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

Currently these build tools takes a dependency on Microsoft.VisualBasic.dll.  There is no good implementation of this DLL on Linux which prevented these tools from running there.  This in turn prevented us from builing VBC on Linux because they are used in the build process.  Change them to instead embed the runtime removing our dependency on Microsoft.VisualBasic.dll.

AsyncRewriter should ignore accessibility in the EE

Fixes #1813

CoreFx work

Remove non-portable dependencies from EEs

Changes cibuild.sh to support the --mono-path option.  When specified
mono from that path will be used in the script instead of the current
mono snapshot.  This will allow us to extend our CI system to include
Mac as well.

Do not report CS1720 warning when member being accessed is a static member.

Adjust implementation of LookupPosition.IsInMethodDeclaration to consider an expression body even in presence of a block.

This adds two scripts that setup a Linux box for building Roslyn. This
represents the steps used to configure our Jenkins CI system for Linux.
The scripts do the following:

- setup.sh: One time machine setup to enable NuGet usage and consumption
  of mono CI builds
- setup-snapshot.sh: Install the latest mono CI package and setup the
  PCL for that build.

These scripts are brand new and should be considered experimental.

closes #2007

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

Fixes internal bug 1086771