Otherwise, if we use 'Compilation.References' instead, then the compiler will spend a ton
of time scanning through those references looking for #r directives.  The compilation tracker
does not care about these, and is only checking actual declared project references.

When you get a compilation from a project in a workspace, it's possible
that the compilation doesn't have all the references you expect. If the
project has references to other languages, we have to produce reference
assemblies, a process that might fail. If it fails, your compilation
just doesn't get references you thought it'd get. Now with this API,
you can ask if the compilation is going to have such missing references,
and act accordingly.

The API is internal for now until get some additional testing on it and
verify it's good for our immediate needs.

Also make it static so it's clear it doesn't look at state.

This reverts commit 15443a23.

Conflicts:
	src/Compilers/CSharp/Portable/CommandLine/CommandLineParser.cs
	src/Compilers/CSharp/Portable/PublicAPI.txt
	src/Compilers/Core/Portable/PublicAPI.txt
	src/Compilers/VisualBasic/Portable/CommandLine/CommandLineParser.vb

Fixes #2888
Fixes #3786

Fell out of our normal cadence for this during the push for RTM. Now that we
had a bit more breathing room getting us back on track here.

Replace AsyncSemaphore with SemaphoreSlim. AsyncSemaphore is no longer
necessary since we moved to 4.5.2

Been almost a month since the code formatter was run so this change was
a bit larger than would be expected for a normal (weekly) update.  Diffs
mostly around:

- Whitespace changes
- Missing copyright headers
- Missing visibility modifiers

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

***NO_CI***
 (changeset 1386846)

Add a very small implicit cache for Compilations. This will hopefully address a regression in Ausgov Winforms caused by the move to explicit caching.
***NO_CI***
 (changeset 1383551)

changed namespace for FatalError to Microsoft.CodeAnalysis for compiler and Microsoft.CodeAnalysis.ErrorReporting for the rest.

it is done so that we can access static fields in FatalErrors. otherwise, it is not possible to see those under debugger in a dump.

also removed FatalError.Report [DebuggerHidden] attribute so that we can set break point there. (changeset 1377507)

The current cost-based cache has no domain knowledge of whether items will be needed again or are safe to collect.  It is therefore usually over-sized. This change implements an explicit cache that must be enabled by consumers. The cache will hold trees and compilations as needed and release them when clients are done with them.

Currently, we enable explicit caching of the active document. Rename tracking and the solution crawler also request caching for each project they process. (changeset 1372494)

Add a diagnostic (not yet part of the toolset) to ensure CancellationToken arguments are last* and fix violations.

* Unless they are followed by params, out, ref, or optional parameters (without themselves being optional), or are interface implementations or overrides.

* I suppressed the warnings in the TaskExtensions and TaskFactoryExtensions types, since we're trying to mirror the TPL's APIs there.

Includes some tests for C# scenarios, and a fixer for C# that just reorders the signature (arguably, it's better to just let the user invoke Change Signature themself). (changeset 1370978)

     ContainsSymbolsWIthName and GetSymbolsWithName which can be used to either check whether certain name exist in the compilation without using symbol or get those symbols that has the name.

     also added corresponding API in workspace layer so that it can be used in IDE as well for things like SymbolFinder

     we are planning to use it further more in features such as "NavigateTo" (changeset 1370769)

This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support.

This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion.

This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio.

Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)

our Logger used to get both FeatureId and FunctionId. FeatureId used to be used to control a group of functionId.

now, I am flattening them so that we can group functionId by its name rather than using both FeatureId and FunctionId. (changeset 1311395)

now cache size can be changed and dynamically configured if we want. (changeset 1308740)

lll
mmm
nnn
unecessary
targetting/targetted
copmilation
egnine
collecton
appropreate
dignostic
diagostic
the a / a the
the the/ a a (changeset 1294596)

     - Introduces VisualStudioMetadataReference that represents a metadata reference in a project system -- this used to be StandardMetadataReference in MetadataReferenceProvider. When this reference is observed by the workspace a snapshot (compiler PortableExecutableReference) is created with a timestamp. We need to create these snapshots and mark them with a timestamp so that we can get back their past state from past solution snapshots.

     - Previous VisualStudioMetadataReferenceProvider (now named VisualStudioMetadataReferenceManager) doesn't derive from MetadataReferenceProvider anymore. MetadataReferenceProvider is meant to support #r directives, not being a base class for all metadata reference factories such as VisualStudioMetadataReferenceProvider. A separate class is used as a MetadataReferenceProvider for compilations.

 (changeset 1223460)

The goal of this change is to allow specification of multiple aliases for a metadata reference and thus simplify code in services and also allow for moving non-portable part of metadata reference property merging out of the compiler.
     As a byproduct this change fixes 2 bugs in the compiler:
     1) Given two copies of a signed strongly named assembly foo.dll copied in two directories A and B one could trick the compiler to accept an incorrect input for which an error should be reported:
         csc /reference:A\foo.dll /link:B\foo.dll

         Currently this just ignored one of the argument (the first one) and embedded interop types. We already reported an error if the references were merged due to paths being the same, but when the identities were the same we just ignored the reference.
         This change reports an error.
     2) <externinfo> custom debug info was only emitted for the first of the extern aliases associated with a metadata reference. We should emit the info for all aliases. I have filed bug 913022 to track a related issue with usings.

     Details:
     Currently MetadataReferenceProperties only allow to specify at most one alias for the reference. User can however possible to specify more than one alias both on the command line and in VS.

     On command line this is done by repeating the /r argument with the same (normalized) path. A couple of examples:
     1)  csc /r:A=foo.dll csc /r:B=foo.dll
           Symbols from foo.dll can be referred to via extern aliases A or B.
     2)  csc /r:A=foo.dll csc /r:foo.dll
           Symbols from foo.dll can be referred to via an extern alias A or without an extern alias.
     3)  csc /r:A=A\..\foo.dll csc /r:B=FOO.DLL
           Symbols from foo.dll can be referred to via extern aliases A or B. The normalized paths are equal.

     In VS the Properties window for a reference has "Aliases" entry where one can type comma separated list of aliases, e.g. "A,B" which corresponds to case 1) above, or "A,global" meaning the same as 2)
     msbuild actually converts these values to multiple references on command line.

     Roslyn VS language service currently needs to create and keep track of instances of MetadataReference for each specified alias, which is complicating already complex code dealing with project and metadata references.

     The ReferenceManager in the compiler compares normalized paths of metadata references in order to find out that it should merge two metadata references. This change keeps that behavior for now, but enables us to move this logic outside of the compiler to csc.exe/vbc.exe. I'll follow up with that change.
 (changeset 1216193)