This modifies the failing tests from '[Fact]' to '[ClrOnlyFact]'. This
disables them on the failing linux build until a fix can be applied.

[Automated] Merge 'stabilization' into 'master'

Extend Linux CI Support

[Automated] Merge 'stabilization' into 'master'

Refactor Compilation to pull features from ParseOptions

Correctly detect option strict on/off when determining if cast is red…

Code Model: Fix issue with parented code model objects corrupting their parents

Don't pretty-list away line continuation characters in VB 9 or earlier

Changes InteractiveWindow.vsct to use image monikers

Port e7dd6093 to stabilization branch

See #3165

Gracefully bail out on extension method rewrite within conditional access expressions

Fixes #2593

User scenario: User types a conditional access expression with a subsequent extension method invocation. For example, "a?.Method().ExtensionMethod()". Attempting to perform any simplification (cast simplification, simplify name) or refactorings (inline temporary) causes a exceptions in the simplification engine and all these IDE services are disabled for the project.

Issue description: We are not handling conditional access expressions, and hence member access or invocations with null "left of dot" nodes, in our expander. Additionally, performing extension method expansion (to a static method invocation with receiver replaced as the first argument to invocation) is non-trivial.

Fix description: This change makes a defensive fix by:
1. Guarding against null reference exceptions.
2. Bailing out on extension method rewrite within conditional access expressions.

Approved 6/4 by ML Shiproom.

Include ContentType into assembly qualified type name emitted for an attribute argument.

Report rude edit when a partially executed active statement is edited

Fix System.String[] sometimes printing in unit tests

Removes old image resource
Reorders sections in InteractiveWindow.vsct to match the schema

Include accessible private members from outer types in Intellisense [stabilization branch]

Port f9bd1d1f to stabilization branch

Conflicts:
	src/EditorFeatures/VisualBasicTest/Completion/CompletionProviders/SymbolCompletionProviderTests.vb

make formatting performance better

...

this performance improvement is particularly for devdiv bug # 1089540

this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine.

there were several issues. each one fixed by

#1, use concurrency on gathering operations.
#2, don't use too much time to split work to chunks if that requires more work than actually formatting.
#3, don't blindly set beginning of a file as inseparable start point for certain formatting options.

...

but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler.
(#3244)

formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally.

but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens)

I opened a bug to compiler team, hopely so that we can get better perf on those APIs.

in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.

Responding to peer review feedback. Updated to never consider user
defined narrowing conversions unnecessary.

Fixes #3161 and Fixes #3163

User Scenario:
User has code with narrowing conversion with an explicit cast.  We will
offer to remove the cast even though this will cause the code to not
compile.

Fix Description:
We previously never consulted optionstrict to determine if a
user-defined narrowing cast was necessary.  The fix in CastAnalyzer.vb
will check if the conversion is narrowing, if option strict is on, or if
we generate a warning on implicit narrowing conversions.  We also offer
to add a cast if an implicit conversion warning is given.

Testing:  Added regression tests + existing tests

Addresses DevDiv 1169511.

Changes InteractiveWindow.vsct to use image monikers
Removes old image resource
Reorders sections in InteractiveWindow.vsct to match the schema

**Customer scenario**: VB customer has legacy project targeting an
earlier version of the language. If they use Visual Studio 2015, we
shouldn't remove their line continuation characters and break their
program.

The scenario this fix directly solves was filed on Microsoft Connect
[here](https://connect.microsoft.com/VisualStudio/feedback/details/1035813/connect-vb-14-compiler-removes-line-continuations-even-when-web-config-specifies-vb-8-as-compiler).
Essentially, this was filed by a customer who has a VB Web Site which
specifically targets Visual Basic 8.0 for legacy reasons and can't use
Visual Studio 2015 with the project.

**Description of fix**: Don't run the Remove Unnecessary Imports code
cleaner if the LanguageVersion is VB 9 or earlier. This addresses the
customer-reported scenario because the VB Web Site project system will
set the language version to VB 9 if the target framework is less than
4.0.

**Testing done**: Unit tests added. Manually verified customer scenario.

Enable xaml project test

This is a fairly involved issue that can manifest in a number of ways.
Currently, the only known scenario where this is exposed within VS is
the "Convert to Web Application" command but there are certainly others
and customers using Code Model could easily run into it.

The scenario is essentially this:

* In Code Model, grab and hold a reference to a code model object for
some container element.
* Access a certain type of child element parented by that container. In
particular, a property accessor, an event accessor, an attribute, an
attribute argument, a VB Inherits statement, a VB Implements statement,
or using directive/Imports statement.
* Try to access a property on the container reference in step 1.
* Exception gets thrown!

Understanding why this happens will require understanding a few of the
system concepts underlying Code Model.

First, Code Model elements tend to have long lifetimes that live through
file edits and even renames. For example, one could grab a reference to
an ```EnvDTE.CodeClass``` and hold onto it. As the user makes edits to
the file containing that class the class element should continute to be
valid (until the user makes an edit that breaks it). Since their
lifetimes can be potentially long, Code Model elements hold onto "node
keys" rather than the SyntaxTree nodes, which they use to get back to
their underlying node in the source file.

Node keys have a very simple format. Essentially, they are the "name" of
the node (qualified syntactically) along with an ordinal which allows
there to be multiple nodes with the same name. Consider the following
code:

```C#
namespace N
{
partial class C
{
void M() { }
}

partial class C
{
}
}
```

In the code above, there are four potential Code Model elements with the
following node keys:

* N, 1
* N.C, 1
* N.C.M, 1
* N.C, 2

Second, some Code Model elements don't actually have node keys. These
are objects that are parented by other code model objects. For example,
parameters are parented within a method or propery, property accessors
are parented within a property, etc. These "keyless" objects can be a
bit tricky because they need to hold a reference to their parent object.

Third, each FileCodeModel maintains a cache of Code Model elements using
their node keys. Whenever a Code Model element is going to be created
for a particular node key, the FileCodeModel first checks to see an
element already exists. If so, it returns the cached element instead.

With that background, here's what's happening:

In several cases, creating a parented keyless Code Model element was
skipping the lookup in the FileCodeModel's cache when creating it's
parent. So, if an element represent the parent already existed in the
cache, a second Code Model element would be created for the same node.
This gets ugly because the process creating a Code Model element causes
it to be added to the FileCodeModel's cache. So, there is an attempt to
add the newly created Code Model element when there's already one
present in the cache with the same node key.

Ideally, this situation would have thrown an exception. However, when
there's a collision, there's a code path in the FileCodeModel's cache
that tries to find a free slot in the cache by changing the original of
the element's node key. This code is super-suspicious and is, quite
honestly, probably wrong. However, removing it is a risky at this point.
So, I'll look at cleaning this up in the master branch.

For now, I've audited all of the places where a parented keyless Code
Model element constructs its parent and ensures that it goes through the
FileCodeModel's lookup.

Fix ITypeSymbolExtensions.IsOrDerivedFromExceptionType to handle type parameters constrained on Exception type or its subtype. Fixes #3254 

Fix a NullReferenceException when setting diagnostic severity.

**Bug:** Fixes #3098.

**Customer Scenario**

1. Customer adds the NuGet package for Microsoft.AnalyzerPowerPack, System.Runtime.Analyzers, or System.Runtime.Interop.Analyzers (really, any package containing FxCop rules implemented as Roslyn analyzers).
2. In the Solution Explorer, the customer expands the References | Analyzers | Microsoft.AnalyzerPowerPack.Common node.
3. User right-clicks on CA2229 and selects "Set Rule Set Severity" | Error.
4. The effective severity of the rule changes to Error.
5. User right-clicks again and this time selects "Default" for the severity, intending to reset it to its default value.
6. The severity is not adjusted, and instead the following dialog pops up:

![image](https://cloud.githubusercontent.com/assets/235241/7825354/dbe7155e-03c0-11e5-819b-5beac1ffd2ad.png)

Note that VS does not crash, and after dismissing the dialog VS continues to function.

**Fix Description**
It is possible to have multiple `<Rule>` elements with the same ID in a
rule set file, so long as they specify the same Action. This is likely
to happen with former FxCop rules--you'll end up with one copy under the
"Microsoft.Analyzers.ManagedCodeAnalysis" analyzer (from FxCop) and one
under "Microsoft.AnalyzerPowerPack.CSharp" or similar (from a Roslyn-based
analyzer).

When the user selects one of these rules in Solution Explorer and sets
the severity to "Default" we need to find each rule with the matching
ID, and remove them all from the rule set file. However, we remove the
rules while we're in the middle of the enumeration, tripping up the
enumerator and leading to `NullReferenceException`s.

The fix is to first flatten the enumeration of items to be removed to a
list, and then remove them.

The first commit in this pull request implements the fix, the next two reorganize the code and add unit tests.

**Testing Done**
I added unit tests around the code in question, include one that fails without the fix.

I also ran through the scenario described above and validated that the rule set was updated as expected after I implemented the fix.

Replace public fields with properties in compiler API

Deal with solutions with circular project references in MSBuildWorkspace

Code Model: When setting the name of a CodeElement, ensure that its members are updated

Port PR #3237 to stabilization -- Catch exceptions when creating a stream for signing