The following line inside GetAliasTarget was causing a deadlock in the
compiler:

bool won = ImmutableInterlocked.InterlockedInitialize(ref
_aliasTargetDiagnostics, newDiagnostics.ToReadOnlyAndFree());

The ToReadOnlyAndFree call caused any lazy diagnostics present in the
DiagnosticsBag to be promptly evaluated.  As a part of evaluation the
diagnostics could call back into other compiler code including
AliasSymbol.GetAliasTarget.  If that happened on the same AliasSymbol
instance the compiler would enter a deadlock as _aliasTarget had already
been set to a non-null value.

The CompareExchange of _aliasTarget is effectively a lock statement
ToReadOnlyAndFree is calling out to untrusted code.  The fix is to stop
doing this by just saving the DiagnosticBag directly vs. calling
ToReadOnlyAndFree.

This resolves DevDiv 1161400

Expose a public API for consumers of CompilationWithAnalyzers to clear off analyzer state cached during analyzer execution.

Executing analyzers requires us to internally store state such as supported diagnostics, registered actions, exception handlers for analyzer exceptions, etc. for the entire lifetime of analyzers. However, the lifetime of the analyzer instances is controlled only by the analyzer host, i.e. the consumer of CompilationWithAnalyzers. We cannot implicitly clear this internal state when disposing CompilationWithAnalyzers as the analyzer host might be re-using the same analyzer instances across multiple CompilationWithAnalyzers instances.

Fix is to expose an API on CompilationWithAnalyzers to allow the analyzer host to explicitly clear stored analyzer state, when it is done using analyzer instances.

Long term solution is to make the AnalyzerManager public and remove its static instance, so that the analyzer host can explicitly control its lifetime.

Add a new command line compiler switch "/reportanalyzer" to report analyzer execution times. Output is grouped by analyzer assemblies and is displayed in descending order of execution times.

NOTE: We do not display the total build time or the ratios between build time and analyzer execution time as the the actual wall clock time for analyzer execution is likely lesser due to multithreaded analyzer execution.

We were previously assuming that "this" was always hoisted in async/iterator state machines.  This is not true in optimized code.

(fixes #2406)

Fixes #1913

When expander encounters an alias identifier that binds to a unbound namespace, it would fall through a code path that would throw NotImplementedException. This change fixes the expander to 'handle' this case without crashing (by simply retruning the IdentifierNameSyntax for the namespace that the alias binds to).

I discovered a difference in behavior between VB and C# SemanticModel which means that although I added a corresponding change to VB's expander, my fix is never invoked. I have logged #2805 for the difference and added a skipped test.

Add ability to write to std err and get the resulting span

...the same way we expand display classes and state machines.  If we see a
local or parameter with a transparent identifier generated/mangled name,
we should instead include the properties of its (anonymous) type in our
list of bindable symbols.

This is a port of ec4d462d

There is one notable difference between C# and VB: whereas C# has a
single mangled name for transparent identifiers, VB has four - $VB$It,
$VB$It1, $VB$It2, and $VB$ItAnonymous.  Fortunately, the differences are
not interesting to the EE - they're only to prevent name collisions
(except $VB$ItAnonymous which is used when the value is not an anonymous
type and does not need to be expanded).

Code Model has several ways of looking at the member nodes of a
particular container. Sometimes it does so recursively, flattening all
nested members into a single list. Sometimes, it looks for "logical"
nodes, i.e. breaking up field declarations into their component
declarators. Sometimes only supported nodes (that is, nodes that can be
properly represented in Code Mode) are expected.

Unfortunately, the internal APIs for these searches grew up organically
and have ecome quite a mess. There were several places where the wrong
search was being used, resulting in strange bugs*.

These concepts are now consolidated into a single GetMemberNodes()
method and all callsites have been reviewed and updated.

* The particular bug that this change addresses is about inserting a
node into a container that contains an incomplete member. In that case,
the code used a "flattened" list to find the index where the node was to
be inserted. What it really wanted was a "logical" list, but that was
conflated with "flattening".

removed unused using and use ProjectGuid from editor rather than defining our own since we have new bits now

Simplifier should not remove parens around ConditionalAccessExpressions that are inside MemberAccessExpressions since this changes semantics.

Fixes #2211

Make constructors of FixAllContext public and add a new nested abstract public type "FixAllContext.DiagnosticProvider" for fix all diagnostic queries.

This unblocks a few product/test FixAll scenarios, see #2709 for details.

Fixes #2725

Fixes #2605 "Lightbulb suggests renaming a type to 'var'"

This change disables using Rename Tracking to rename to/from "var" and "dynamic" in C#.

We need to normalize absolute paths before comparing them. Otherwise we
may compare `C:\Alpha\Beta\Delta.dll` and
`C:\Alpha\Beta\Gamma\..\Delta.dll` and decide they are not the same.

Runtime binder calls take a System.Type that they use for things like
accessibility checks.  The expression compiler was incorrectly passing the
result type it synthesized and the regular compiler was incorrectly
passing a nested type in the async lambda case.

Fixes #878

Currently, if a .ruleset file is renamed, deleted, or removed, we only
update the `CodeAnalysisRuleSet` property on projects that included the
.ruleset as a project item. This commit institutes better rules:

* If a project- or solution-level .ruleset is renamed, we need to update
every `CodeAnalysisRuleSet` property containing the old name in every C#
and VB project--even if the .ruleset isn't a file in the project.
* If a project- or solution-level .ruleset is deleted, we need to clear
every `CodeAnalysisRuleSet` property containing the name in every C# and
VB project--again, even if the .ruleset isn't a file in the project.
* If a project-level .ruleset is removed, we only clear the
`CodeAnalysisRuleSet` properties for that project.
* If a solution-level .ruleset is removed, we do nothing.

Fixes #1601.

This deletes the empty and unused Desktop assemblies from the code base.