Avoid a couple of VB iterator allocations for emitting custom attributes and interfaces. Combined, this is 0.5% of allocations in the "Roslyn Full" build. (changeset 1412086)

1. Reduce allocations when reading from FileStream.
2. Pre-compute checksum if possible.
3. Reduce allocations for lazily computed checksums.
4. Avoid LOH allocations for large source text.
5. Update EditorTextFactory to optimize for reads from temporary storage

Perf results for the Picasso rebuild scenario:
184 MB total allocations saved. Including: 78 MB of char[], 73 MB of Byte[], 9 MB of string. Also, 35 MB of LOH allocations were eliminated.
 (changeset 1412085)

In a benchmark with 200,000 methods in a type, ChildThatContainsPosition was the clear bottleneck. For such cases, the syntax list is represented using a special type called WithLotsOfChildren (both VB and C# have this optimization) that has a constant-time implementation of GetSlotOffset. Given that, we can find the correct slot via binary search instead of a linear search.
With this change, the benchmark compilation went from 45 seconds to 25 seconds. (changeset 1412034)

CR: jasonmal;joshs;jaredpar;hechang (changeset 1412012)

Move Roslyn.DebuggerVisualizers to open. This project contains VS debugger visualizers of IL, PDB and metadata blobs helful for debugging Roslyn issues. (changeset 1411991)

Disable Microsoft.VisualStudio.LanguageServices.Implementation.EditAndContinue.VsENCRebuildableProjectImpl.TrackingSpansChanged(bool) pending perf investigation (issue #291). (changeset 1411936)

 (changeset 1411873)

No, if you search for something like CS.SK we'll find Microsoft.CodeAnalysis.CSharp.SyntaxKind

We do this by breaking up the original pattern by dots (so, in this case, we'd have "CS" and "SK").  We then do our normal search, looking for symbols that match the last name piece (in this case "SK").  When we find one, we then walk up it's container seeing if each parent container name matches each respective preceding pattern component.  If all pattern parts match, then the symbol is a match and it is returned.
***NO_CI***
 (changeset 1411849)

Update the helpers that recognize member access and DataTipSpanGetters.

Fixes DevDiv #1077843.

CR: JasonMal, VladRes (changeset 1411839)

As part of hardening code in the debugger to handle module resolution failure, DkmClrModuleInstance.GetLocalSignatureToken can now throw FileNotFoundException when the module cannot be resolved.  This can happen when debugging dumps without heap.

Fixes DevDiv #1118606.
CR: PaNelson (changeset 1411814)

If a PublicAPI.txt file includes a symbol that is not found in the assembly we will create an error stating that an API has been deleted. We put this error in the PublicAPI.txt file, but do not currently include the line number.

With this change we now search for the proper line, and include it in the diagnostic. (changeset 1411808)

1. I had changed the preview pane service to just return the preview object that was passed in in cases where we have no additional information to display (e.g. in the case of refactorings, there is no diagnostic and so there is no need to add a diagnostic header). Unfortunately, the passed in object (IWpfDifferenceViewer) is not a wpf control that the platform can display - so this change ended up causing us to stop showing a preview in such cases. I changed the code back to do what it was doing before my change (i.e. get the visual control from from the passed in IWpfDifferenceViewer and wrap that with the preview pane). We'll need this later anyways once refactorings get headers...

2. In cases where header was absent, we were still displaying a spurious separator between non-existent header and the preview diff view. Changed the code to only display the separator when required. (changeset 1411804)

Automated checkin: update Concord binaries from \\cpvsbuild\drops\dev14\VSPro_1\raw\22605.00 to version 22606.00.
***NO_CI***
 (changeset 1411647)

Automated checkin: update Concord binaries from \\cpvsbuild\drops\dev14\VSPro_1\raw\22605.00 to version 22606.00.
***NO_CI***
 (changeset 1411620)

     * Gray background
     * No border
     * No padding on top or right
     * Colored bar at bottom of dashboard

     This requires us to set UseLayoutRounding=True, since we're trying to draw straight lines (https://msdn.microsoft.com/en-us/library/system.windows.uielement.uselayoutrounding%28v=vs.95%29.aspx). (changeset 1411219)

Update SyncConcordBinariesTask.xml (scheduled task) to reflect the script's new location. (changeset 1411140)

Include the actual license text.

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 1411068)

Consider what happens if you have two analyzers, A and B, that each depend on an assembly named C.

  Directory 1:
    A.dll
    C.dll

  Directory 2:
    B.dll
    C.dll

If both copies of C have the same identity (name, version, culture, public key token, etc.) then only one of them is actually going to be loaded into VS. If both copies are identical then it doesn't matter, but if their contents differ the analyzers may not work the way they are supposed to or may fail outright.

Here we attempt to let the user know that this might happen. Whenever an analyzer is added or removed we identify the transitive set of assemblies the analyzers' may load and identify assemblies that have the same identity. We then hash the file contents of these assemblies and compare. If they are different we surface a conflict in the Error List.

In solutions with many different analyzers or dependencies this is a potentially expensive operation. To limit the impact on the system we only allow one of these operations to run at a time. If an analyzer is added or removed while a check is in progress we immediately signal for cancellation, wait for the existing task to finish up, and only then start the new one. (changeset 1411056)

When the DeclarePublicAPI analyzer was first put to use there were a couple of bugs in the compiler and IDE analyzer drivers for VB projects; this effectively limited the analyzer to C# projects. These have now been fixed, and it can be turned on for VB. (changeset 1411047)

Expose the compiler's helper to find ConditionalAccessExpressions at the Workspace layer. 1113971 tracks making this a public API in the compiler. (changeset 1411035)

DescriptionModifyingCompletionItem should use the default task scheduler when computing the snippet text. Use of "TaskScheduler.Current" will deadlock if the UI thread is blocking waiting for a description."TaskScheduler.Current" would deadlock if the UI thread was blocking waiting for a description.

Note that this was previously checked into Dev14CTP as changeset 1350549 but somehow didn't get included when that branch RIed to Roslyn\Main. (changeset 1410908)

Fix bug 1042696. Changing shape of syntax nodes representing XML document literals, as was planned initially, proved to be risky and time-consuming approach. After discussing this issue with KevinPi, I decided to apply a simpler fix on the compiler side (basically, a rollback of the changeset 1071554 that introduced this breaking change -- approved by the triage at that time). With this fix, the trailing whitespace is accepted and parsed as trailing trivia on the last token in the XML document. This fixes the compat break in the compiler, and extends the set of valid VB programs. But it requires reactivating IDE bug 602208, because some of the newly valid programs are not automatically supported by all refactorings (nothing that was previously working is being broken by this changeset - it just was OK that those programs were not supported because they were invalid). (changeset 1410876)

1. Stop displaying superfluous 'No Preview' under the header section of the preview pane for fixes such as 'rename tracking' and 'generate type dialog' that don't provide any visual preview.

2. Make preview pane header font use the VS 'Environment' font settings so that user can change /scale the font.

3. We were not displaying the preview header in the case of hidden diagnostics (which don't show up in the error list) - start displaying the header for hidden diagnostics (except if the diagnostic is a 'trigger' diagnostic).

4. Disable tab stop / focus in the code diff view portion of the preview pane. When using keyboard, we were allowing user to stop in the diff view portion - this ended up causing confusion since we would display a blinking cursor in the code diff view portion giving users the impression that they could type something there.

5. Set Focusable=true on the preview pane control. Light bulb checks for this before shifting keyboard focus to the preview pane in the case where there are no 'flavored' actions under the preview pane (such as 'Preview Changes' and 'Fix All Occurrences'). (changeset 1410707)