Don't attempt to retry if we're asked to load the same assembly identity more than once.  Adding the same reference won't help anything, and we will almost certainly never terminate the retry loop.

This is the first of a sequence of changes.  We associate additional
information with each type that comes from the expression compiler.  For
now, it is the bool[] from the DynamicAttribute on the return type of a
method synthesized by the expression compiler.  (The bool[] is packed into
a byte[] for generality and compactness.)  Then, as we traverse the type
in the type name formatter, we consume the flags to determine which
occurrences of "object" should be replaced by "dynamic".

We don't show "dynamic" everywhere we could (e.g. in base type names in
disambiguators), but I believe we show "dynamic" everywhere the legacy EE
did.

TODO: The expression compiler doesn't call the new API to pass the
appropriate dynamic flags (API pending).

TODO: The expression compiler doesn't consume dynamic flags on
pseudo-locals (API pending).

In Windows 8 (and 8.1), runtime winmds may contain assembly refs pointing
to other runtime winmds (for example, types defined in Windows.UI.Xaml
point to Windows.UI).  However, when the EE sees these assembly refs it
must redirect them back to the compile time contract assembly (Windows),
because the Compilation used by the EE only references the contract Assembly,
not the various runtime Assemblies.  Previously, we only did this redirection
for Windows 10.  Non-EE cases should only see the contract assembly at
compile time, so this change will not affect them.

Ignore enums in OverrideMethodsOnComparable analyzer and codefixer.
fixes #1994

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

Fixes #1504.

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.

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

Fixes #971.

Also disable a unit test that fails with new toolset.

TryCombine should never throw exception.

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.

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.

Fixes #1942.

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

Fixes internal bug 1086771

First is cleanup some infobar code such as adding copyright header, adding internal, removing unused usings and etc.
Second is adding more info in exception log.
Last is making code action more resilient to null return value from user code.

Fix #1980 : CodeModel was not handling Conversion operator declarations
in few areas. This change addresses these issues

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

Fixed #1702.

This changes the following:

- Changed the fallback encoding for EncodedStringText to Latin1 instead
of code page 1252.  The latter is not supported on CoreCLR so using the
more general Latin1.
- Change the VB compiler code base to be CoreCLR compatible as well.

Fixes issue #1845.