* Arcade SDK 1.0.0-beta.19054.11

* Consolidate OptProf scripts

* Use raw IBC data from VSTS drop

* Fix issues with using dogfood compilers

* Replace Restore-Project with Run-MSBuild.

Run-MSBuild sets various properties based on global variables that were not set in Restore-Project.

The point of using the bootstrap compiler is validating that we can
build the C# code base with the latest C# compiler. Unfortunately the
debug version of the compiler is significantly slower than the Release
version and it slows down our Debug unit test runs accordingly.

This change causes us to prefer a release version of the bootstrap
compiler. The debug bootstrap compiler is still used in the determinism
leg hence we wont't lose coverage here. This should bring our Release
and Debug desktop tests back to the same run time.

* Remove RuntimeIdentifier specification

* Arcade directory layout

* Use Arcade dotnet install scripts

* Update roslyn-tools build tasks to 1.0.0-beta3.18523.2

* DotNet version check, remove LocateDotNet.

The `&` operator in Powershell does not easily allow arguments to be
conditionally emitted into a command. This is because instead of
inserting string contents when using variable replacement it will insert
a quoted string instead. Using `Exec-Process` instead as it does proper
substitution

https://github.com/dotnet/announcements/issues/77 for the change and
where I am stealing this change from.

https://github.com/dotnet/announcements/issues/77 for the change and
where I am stealing this change from.

On our 15.8 machines, there aren't release versions...because we haven't
released it yet.

* Orchestrated build dependency uptake

* Remove duplicate NuGetPackageRoot definition

Moved the last of our NuGet package creation over to dotnet. Deleted all
remaining infrastructure for using NuGet.exe.

In the case the CLI was previously downloaded but not yet on `%PATH%` we
need to manually add it there. Not doing it leads to cases where MSBuild
can't find the proper SDK and as a result failing the build.

closes #25649

DevDivInsertionFiles.vbproj is the last project which isn't included in
Roslyn.sln. Included it there and remove the solution that used to drive
it's build.

* Remove duplicate lock DocumentState.s_syntaxTreeToIdMapLock

This lock is only being used to protect access to an instance which contains
internal synchronization.

* Better handle surrounding directives when inlining a local variable.

* Add tests.

* Share code between VB and C#.

* Reduce allocations in UnboundLambda

Fixes #23463

* Restore ReturnInferenceCacheKey as the key for _returnInferenceCache

* Update code to more closely follow patterns of the original code

* Cleanup from code review

* basic fix for intellisense in Immediate window

* better comments and cleanup

* Add basic integration tests

* cleanup inproc Immediate window integration test helper

* fix incorrect comment

* address PR feedback

* create Immediate window on ImmediateWindow_InProc.GetText()

* Verify MSBuild version in Developer CMD prompt

Roslyn is designed to have the simplest possible contribution story:
clone then build. Every pre-req needed is either located on the machine
or bootstrapped via NuGet. All the way down to using an xcopy MSBuild if
needed.

The one case which causes a problem is the VS command prompt. In this
case MSBuild is pre-installed on the machine and may or may not be
suitable for building Roslyn.

Previously when building from a VS command prompt we just used whatever
MSBuild was provided. The assumption being a developer command prompt
was an explicit statement of whath MSBuild you wanted to use. Based on
all of our customer reports though this does not seem to be the
assumption that consumers of our repo have. The build gave them no
explicit errors about the provided toolset and hence when the build
failed they assigned flakiness to our repo.

Going forward we are applying the same version validation to MSBuild
when provided via a developer command prompt. If it doesn't match we
will refuse to build asking the user to upgrade VS or build from a
normal command prompt.

* Remove unneeded debugging line

* Comment about pre-release

* Added minimum version

* Add Omit If Default style option

* Add space to be like test without the omit

* Add/Remove without needing a property

* Reformat

* PR feedback

* Fix VB diagnostic based on feedback

* Handle case of NotApplicable modifier and field declaration list

* Fix tests

* PR feedback

* PR feedback

* PreviewCodeAction was overriding ComputeOperations but returning a post-processed operation from original action. This results in another PostProcess being called on the codeaction. If postprocess was overriden in originalaction that'll be ignored the second time (#23920)

* Support negative null-check when we are suggesting to inline type checks

Fixes #21097
Fixes #24286

* fix a case where persistent storage registration fails and some clean… (#24458)

* fix a case where persistent storage registration fails and some clean up code around it.

* added readonly

* address PR feedback

* removed comments no longer relevant

* renamed lock name

* moved waiter from diagnostics.dll to features.dll where all interfaces are defined. (#24512)

* put listener change back in (https://github.com/dotnet/roslyn/pull/24120)

* leave old types in legacy folder until partner teams move to new interface

* added legacy waiter to support partner teams

* Remove methods indirecting access to _metadataFileNameToConvertedProjectReference

This field is documented as being written and read from any thread,
but in practice all uses are guarded by an AssertIsForeground(). Thus
we can get rid of the helper methods that are trying to "help" by
locking before accessing the fields, making it really hard to track all
the real uses of it.

* Make method static that doesn't need state

* add a comment to address PR feedback

* Fix up tests of P2P to metadata reference conversion

It turns out we had some tests, but the tests were disabled. This was
because the tests weren't working properly anyways: they were calling
into UpdateProjectBinPath which only updated some (but not all) of
the project state. That was an internal helper method that shouldn't
be used by tests. Updating the tests to use
SetBinOutputPathAndRelatedData works better.

* Delete debug-only reference validation

This was some legacy code that tried to verify that the references
we have from the project system match up to what DTE and other sources
say. This was debug-only, and the actual asserts were commented out.
This is deadweight at this point, so delete it.

* added and cleaned up logs around build and live diagnostics. (#24551)

also added RoslynActivityLogger that can be enabled through project-system-tool

* Avoid closure allocations on the BindSyntaxTreeToId fast path

* CS1628 error text mentions in parameters; fixes #24584

* Small cleanup of completion logic.

* Move to xunit.console for CoreClr tests

Previously we were using xunit.console for desktop tests and dotnet-xunit for our
CoreClr tests. This change unifies us on top of xunit.console (now that it has a
netcoreapp2.0 version available).

* Move unix builds to xunit.runner.console as well

* Get actual directory name, not file

* Fix dir name issue

* fixed build break

Roslyn is designed to have the simplest possible contribution story:
clone then build. Every pre-req needed is either located on the machine
or bootstrapped via NuGet. All the way down to using an xcopy MSBuild if
needed.

The one case which causes a problem is the VS command prompt. In this
case MSBuild is pre-installed on the machine and may or may not be
suitable for building Roslyn.

Previously when building from a VS command prompt we just used whatever
MSBuild was provided. The assumption being a developer command prompt
was an explicit statement of whath MSBuild you wanted to use. Based on
all of our customer reports though this does not seem to be the
assumption that consumers of our repo have. The build gave them no
explicit errors about the provided toolset and hence when the build
failed they assigned flakiness to our repo.

Going forward we are applying the same version validation to MSBuild
when provided via a developer command prompt. If it doesn't match we
will refuse to build asking the user to upgrade VS or build from a
normal command prompt.

The dotnet pack command can't handle nuspec files (or at least I can't
find the appropriate documentation for it). As such contining to use it
for creating NuGet packages for now.

As written our restore is treating every package in the toolset project
as something to be included when building the project. This causes NuGet
to construct a completely non-sensical project.assets.json. Exclude
everything so that the resulting file is valid.

These were moved in https://github.com/dotnet/roslyn-sdk/pull/21

The abscence of the 2.0.0 shared runtime seems to be the cause of our
CoreClr based suite failures. Hard coding the download of the runtime to
verify this is the case. Will work on a better fix after it's verified.

When looking to see if we have the proper CLI installed for building
need to check the SDK dir, not the CLI directory. This ensures that when
we change SDK versions being used we download the appropriate SDK and
don't accidentally used the previous install.

This merges the base and core toolset files into a single project file.
It uses multi-targeting to achieve the effect of having multiple files.

The toolset packages were all restoring to the source directory. This
violates our build principal of builds should never write to the source
directory.

Changed to restore to the Obj directory as the rest of our code does.
Temporarily went back to the old MSBuild syntax. This will move to the
new MSbuild syntax with the rest of the repo.

The general principal here is that source directories should be
immutable. Ideally builds should be done with the write permissions set
to deny on the entire source tree. Having an immutable source tree helps
ensure that:

- Builds are repeatable: Any mutation, even simply new files, means it's
new input for the next build to see and potentially alter behavior.
- Builds can run in parallel: The source tree is read many times during
build. Any mutation to the tree can impact parallelization as order of
reads and writes must now be taken into account.

This lets us avoid hard coding in version numbers for the core tools
we use in our build.