Background:

As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

The coding style transition is automated using a Roslyn based rewrite tool:

https://github.com/dotnet/codeformatter

This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1403394)

It turns out the code in Solution Explorer to calculate the effective severity for a diagnostic (and thus show the correct icon) was using the diagnostic's enabled-by-default flag and the compilation's general diagnostic option in the wrong way.

If a diagnostic is disabled by default, then the only thing that can turn it on is a specific diagnostic option, not the general diagnostic option. Also, the general diagnostic option can only turn a warning into an error, or suppress a warning or info. (changeset 1403379)

Adds Microsoft.DiaSymReader public library that provides interop interfaces and helpers needed for work with PDB format via DiaSymReader.  (changeset 1402865)

Compat: Suppressing branch-coalescing optimizations in certain rare cases where it can result in extra work in JIT or even expose JIT bugs.

== Consider the following code:

        try
        {
            try
            {
                // SOME CODE
            }
            catch (Exception ex)
            {
                Console.WriteLine("catch1");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("catch2");
        }

=== It's IL equivalent is

        try
        {
            try
            {
                // SOME CODE
                leave LABEL1;
            }
            catch (Exception ex)
            {
                Console.WriteLine("catch1");
                leave LABEL1;
            }
LABEL1:
                leave LABEL2;
        }
        catch (Exception ex)
        {
            Console.WriteLine("catch2");
                leave LABEL2;
        }
LABEL2:

Note that LABEL1 is technically redundant. All branches to LABEL1 can as well point directly to LABEL2.
Indeed, branch optimizer notices this fact and morphs the code into more compact:

        try
        {
            try
            {
                // SOME CODE
                                leave LABEL2;
            }
            catch (Exception ex)
            {
                Console.WriteLine("catch1");
                                leave LABEL2;
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("catch2");
                    leave LABEL2;
        }
LABEL2:

While semantically it is a valid transformation, it creates two issues related to handling of Thread.Abort :

1) if Thread.Abort happens while running SOME CODE, then the first catch will catch it, however since it is not explicitly suppressing the propagating of the thread abort, the exception must be rethrown by the runtime. The inconvenient part here is that the exception must be rethrown when running some code outside of the inner try, but inside the outer try. Since there is no such code in this IL, JIT must detect this situation and do some code injection that is similar to basically undoing the optimization that C# compiler did.

Considering that the only thing that we gain here is removing one LEAVE instruction at the cost of requiring JIT to essentially put it back, it does not seem that the optimization is very profitable.

2) The part where JIT detects such cases and special cases them is _very_ delicate. There appear to be a variety of bugs in different JITs which result in missing this case in one form or another resulting in some handlers not being run as expected.

Indeed, it has been always possible and is still possible to introduce this case by hand via explicit goto statements and cause bad behavior. These issues would be not new and only JIT developers can fix them.

However introducing this case as a result of optimizations causes compatibility issues where some code that formerly worked no longer works when recompiled with Roslyn, because there are cases that Dev12 compilers did not optimize.

To mitigate the compat issues we will explicitly suppress label-coalescing optimizations when they may result in a label to "move out" of a region protected by a catch.

 (changeset 1402671)

When SourceText.From(stream, encoding) detects encoding from BOM it should use that encoding instead of the encoding specified by the user. The new behavior is consistent with StreamReader. (changeset 1402610)

Compare encoding names rather than the encoding objects themselves (as the encoding object is not a singleton).  My previous attempt to fix this ignored the fact that we never actually pass the encoding object to the Workspace or EncodedStringText constructor. (changeset 1402410)

Ensure that SemanticModel always gets the same bound tree for a Const local initializer regardless in what order statements are bound.
***NO_CI***
 (changeset 1401983)

These two projects have been superseded by the OpenSourceDebug project, so there's no reason to keep them around. These were also where the PackageLoadKey attribute was defined for any C# source project, and we don't need that anymore either -- so delete all uses of it and related resources.

This project also had some side-effects regarding signing of compiler files. That was fixed in an earlier checkin. (changeset 1401945)

***NO_CI***
 (changeset 1401865)

***NO_CI***
 (changeset 1401854)

Prevent TypeScript projects from being included when FindRefs is searching for dependent C#/VB projects to search in.
***NO_CI***
 (changeset 1401778)

When a file is replaced on disk its timestamp should be set to the most recent of its creation time and last write time.

Also updating FileKey to use last-write-time, since that's what it's comment explicitly calls for. (changeset 1401724)

MEF sometimes ends up populating returned arrays for IOrderableMetadata.After and IOrderableMerada.Before with null entries. This used to be harmless until recently - but is no longer harmless after the recent API change that made the ExportCodeFixProviderAttribute.Name property for code fix providers optional.

If a code fix provider does not specify a Name via this attribute, then the above MEF behavior means that we end up seeing cycles in our extension ordering implementation. The previously harmless nulls inside ExtensionOrderAttribute.Before and .After are perceived to be the same thing as the code fix providers with null names - and because MEF can return null entries in both the .Before and .After collections, extension orderer thinks that we have a cycle with the same (null-named) fix provider being ordered both before and after some other fix provider. The orderer then throws an exception and we refuse to offer any fixes to the user in the lightbulb. Worse still, the only thing that the user can do to recover from this situation is to figure out and remove the fix provider that has a null Name from the mix.

There are two issues that needed fixing here -

1. Fix providers with null names should never cause accidental cycles like above. We filter nulls out of collections returned from MEF to avoid such cycles.

2. Even if someone intentionally created a cycle (by placing same extension before and after another via [ExtensionOder()] attributes), we should never crash. We should break the cycle but avoid the crash - light bulb should continue to offer all available fixes even if a conflict is detected in the ordering.

Also discovered that the CSharpConvertToAsyncMethodCodeFixProvider was using incorrect name + that EncapsulateField refactoring was not listed in PredefinedCodeRefactoringProviderNames. Fixing both issues. (changeset 1401689)

Rollback changeset 1401587 as it is causing MetadataShadowCopyProviderTests to fail. (changeset 1401641)

When a file is replaced on disk its timestamp should be set to the most recent of its creation time and last write time. (changeset 1401587)

This change updates VB warning titles to remove an ending periods. This does not affect the actual text of the message in any way, just the titles you see in the rule set editor. (changeset 1401584)

VB: Adjust logic used to decide whether InternalXmlHelper class is going to be embedded into a compilation.

Rather than checking names of referenced assemblies, compiler explicitly checks for availability of types the implementation of InternalXmlHelper depends upon. These are the types explicitly referenced by the code:
System.Linq.Enumerable,
System.Xml.Linq.XElement,
System.Xml.Linq.XName,
System.Xml.Linq.XAttribute,
System.Xml.Linq.XNamespace.

This adjustment should enable usage of XML literals while targeting PrjectN and similar framework flavors.

For the purpose of the check, the type is considered available if an accessible type with the required name is declared in at least one of the referenced assembly.

***NO_CI***
 (changeset 1401127)

As in the original C# implementation of Color Color handling, the Color Color handling in the VB binder originally used lookup to decide the meaning of an ambiguous identifier as a simple name or type name instead of binding.

Unfortunately, this is not correct: the meaning of an identifier as outlined in the spec is defined by binding. This caused the compiler to incorrectly fail to recognize Color Color in situations where a simple name or type name lookup is ambiguous but a bind of the same is not. This change replaces the lookups used in Color Color with binds, which brings Roslyn's behavior back in line with Dev12 and the spec in cases that fit such cases.

This change is likely to be slightly perf-positive in cases involving a simple name that does not bind to a symbol that qualifies for the Color Color rule: in this case, the old code performed a lookup followed by a bind, whereas the new code simply performs a bind and returns the result. There is likely to be a perf penalty in a true Color Color case, however, as the bound node is larger and the new code is unconditionally binding the type even in the case where the type will not be used (whereas the old code would simply look up the type).
***NO_CI***
 (changeset 1401089)

C#: Null-conditional Access in context of an expression-bodied void method or a void expression lambda should be allowed even if result type of the access cannot be made nullable.

***NO_CI***
 (changeset 1401026)

don't descend into GlobalNameSyntax when getting a node's name and avoid the 'Global.' prefix. (changeset 1400952)

Compiler AnalyzerDriver processes compilation events sequentially, but executes analyzer actions for each event in parallel. This doesn't work well with analyzers that are not thread-safe, and we don't expect everyone to write thread-safe high performant analyzers. Until, we add some support to analyzers to allow it to specify whether or not it is a thread-safe analyzer, we should disable concurrent execution of analyzer actions for every analyzer.
This change primarily does couple of things:
1) Group analyzer actions by analyzer in the AnalyzerDriver.
2) For symbol declared events, create a task chain per analyzer with continuations added for executing actions for that analyzer. For other compilation event kinds, we can just execute actions per-analyzer in a single task.
This change is *expected* to increase the overall build time as we lose concurrency of analyzer execution, but hopefully that will be pulled back when we add support for registering an analyzer as thread-safe analyzer and mark all our analyzers as thread-safe. (changeset 1400884)

Renames various "Begin" and "End" property names in Syntax API to match the rest of the API with block specific names like "CaseStatement" "EndClassStatement" etc (changeset 1400806)

Between all of our different processes, xUnit, Jenkins, Test.exe, etc ... our unit tests run on a variety of xUnit runners.  A number of them are unable to handle the following pattern:

     [Fact]
     void M() { ... }
     void M(string arg) { ... }

     Essentially a test method which has an overload in the same type.  This is clearly a bug in xUnit and one that is fixed in more recent versions of 2.0.  We are in the process of updating to that version but it will take a bit more time to do so.  In the mean time I wrote a program to find instances of this pattern and changed the code to work around this temporary issue.   (changeset 1400484)

***NO_CI***
 (changeset 1400352)

Note: I still need to come back and change the unit tests to use AssertTheseDiagnostics.  But I need to get this change off my machine at the moment so I can push through a few other items.  (changeset 1400296)

Generate SymbolDeclaredEvent for VB enum symbols (SourceEnumConstantSymbol). Currently, we generate the event only for SourceMemberFieldSymbol. (changeset 1400251)

Fix VisualBasicDeclarationComputer.GetDeclarationsInSpan to work for statement syntax nodes without a parenting block. (changeset 1400250)

Update Microsoft.Net.ToolsetCompilers and Microsoft.Net.RoslynDiagnostics to version 1.0.0-rc1-20150116-01.

Also turn on the DeclarePublicAPI analyzer for all of the C# assemblies that end up in our NuGet packages. I can't turn the DeclarePublicAPI analyzer on for our VB projects yet due to bugs in the analyzer driver. (changeset 1400249)

Fixed problem with open documents not always setting preservation mode to PreserveIdentity.  (changeset 1400158)

When showing completion after a MemberBindingExpression in C#, we used to find the closest parent ConditionalAccessExpression. With this approach, invoking completion before "b" in "a?.b?.c" will show members of b instead of a. We must instead walk up the tree until we find the first ConditionalAccessExpression whose question token appears before the start of the MemberBindingExpression (this is also what the compiler does). This is exposed as an extension method so other IDE features can consume it. (changeset 1400157)