Allow snippets in Inline Diff View

No conflicts on same-named locals of delegate types

Use pkgdef matching the language

Allocation reductions in formatting.

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

Add a new command line compiler switch "/reportanalyzer" to report analyzer execution times

Fixes internal TFS bug #831378

Invoke snippets on the DataBuffer instead of the EditBuffer. Once
IVsExpansion.InsertExpansion/InsertNamedExpansion has been invoked
on the correct buffer, all remaining processing is the same
(formatting, end span tracking, and snippet functions all map their
given spans down to the subject buffer for processing).

fixed typos mentioned in #2786 and #2787

Fixes #1729

The C# implementation of IRenameRewriterLanguageService.LocalVariableConflict was returning conflicts any time a related invocation expression bound to a local/parameter, but this condition is not indicative of a conflict when the local/parameter is of a delegate type. This change prevents reporting this particular kind of conflict on references to locals & parameters of a delegate type.

EE: Ignore duplicate types from cor library

Ignore types from the cor library that also exist in the other framework assemblies.
This issue arises in the EE when compiling expressions against the runtime assemblies loaded in the debuggee for CoreCLR.

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.

Fixes #2576

Adds an assert to clarify assumptions of GetAssemblyReferenceAlias

Rollback fix d23b86, which turned out to break the EEs

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.

Fix issue with locating source method in optimized code...

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

(fixes #2406)

Fix expander to not crash when it encounters alias that binds to a missing namespace.

 Fix issue where stdout and input aren't interleaving correctly

Expand transparent identifier in the (VB) EE

Rationalize Code Model "member node" logic

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.

Revert change to VS Setup to include the build task

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".

Update toolset compilers and analyzers.

Update to version 1.0.0-rc3-20150510-01.

add base list before trailing trivia

moved tableControl APIs to the new ones