Standardize the conditional IOperation verification skip method, and fix a bug that caused it to skip in exactly the wrong way.

The CLI toolchain only supports string literals inside of a RESX file.
Other blobs, such as a reference to a file on disk, are not supported.
Instead their value gets embedded directly as a string literal (type is
ignored). Only supported mechanism is to embed them as a manifest
resource stream.

https://github.com/Microsoft/msbuild/issues/2221

More renames of Visual Basic Test Helpers to match the counterparts in
the CSharp code

Getting a couple of parameter names in line with the C# counter parts:

- source: how the test source code is specified
- references: how additional references to the compilation are specified

* Rename Foo to Goo

* Rename ifoo to igoo

* Add back BOMs

Now that the comment formatting issue is fixed in the Formatter type, we can run the formatter on the remainder of the VB code base.

closes #1424

There were some issues getting xunit to respect the -notrait option
hence we decided to simplify and use ConditionalFact

This change allows provides the option of running our tests in 64 bit
mode.  Simply invoke BuildAndTest.proj in the following manner:

> msbuild /v:m /m BuildAndTest.proj /p:Test64=true

There are a set of tests today that don't run correctly in 64.  All have
been annotated with the trait

> Require32=true

We need to push on these to get a clean 64 bit run.  But short term this
will at least give us protection against regressions.

Fix a bug in the adjusted Color Color code that failed to correctly account for instance members on base types.
***NO_CI***
 (changeset 1404916)

Before this change, Roslyn used a slightly different Color Color rule for Visual Basic than the Dev12 compiler. Where the Dev12 compiler's rules would never result in an unresolvable ambiguity, the Roslyn compiler's could, particularly if the LHS required late binding or had errors. The Color Color rules have been therefore been adjusted to make decisions in the same manner as Dev12 for late-bound cases (where we must be compatible). The new rules are given below.

If the base expression of a member access expression is a simple name and binds to a constant, field, property, local variable or parameter whose type has the same name, then the base expression can refer either to the member or the type. This can never result in ambiguity because the members that can be accessed off of either one are the same.

In the case that such a base expression binds to an instance member but the binding occurs within a context in which "Me" is not accessible, the expression instead binds to the type (if applicable).

If the base expression cannot be successfully disambiguated by the context in which it occurs, it binds to the member. This can occur in particular in late-bound calls or error conditions.
***NO_CI***
 (changeset 1403686)

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)

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)

1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique.
     2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead.
     3) Removes GenerateTempNumber from TypeCompilationState. Combination of method ordinal and other indices is used to make generated names unique:
     - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name.
     - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method).
     - The same for fields caching lambdas.
     - Delegate relaxation stubs and their closures have a separate numbering and are distinguished from regular lambdas/closures, since they are immutable and EnC doesn't need to map them across generations.
     - Late-bound AddressOf operator oddly creates real closure and is thus not considered a delegate relaxation for the purposes of synthesized naming.
     - Properties generated to override inherited WithEvent properties are assigned ids in the source order of Handles clauses.

     In order to guarantee uniqueness of the names added during EnC include generation ordinal in synthesized names  wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation. (changeset 1395267)

This is consistent with the spec and Dev12.
***NO_CI***
 (changeset 1387266)

Porting the recent C# changes to support EnC for VB Async and Iterator. (changeset 1384053)

This way we can have better performance of invocations while keeping parameter list of delegate.Method backwards compatible.

The approach is basically always to emit backing methods into a display class, just that in a case of lambdas not capturing anything, the display classes will not have any fields.
Also, when display classes do not have any fields, lambdas of all nongeneric methods in a given class can share the same display class and in fact can share the same singleton instance.

***NO_CI***
 (changeset 1359307)

***NO_CI***
 (changeset 1356181)

Abbreviates the public VB-specific types (e.g. VisualBasicSyntaxTree -> VBSyntaxTree) in accordance with the .NET Class Library Guidelines to avoid overly lengthy names and consistent with the conventions used in other APIs (e.g. VB CodeDom). (changeset 1348499)

This shelveset implements following changes to metadata reference compiler API in order to remove duplication in the public surface and prevent users from unexpected metadata lifetime issues:

     1) MetadataImageReference and MetadataFileReference overlap
     Currently MetadataImageReference can be constructed from a Stream. MetadataImageReference supports metadata prefetch (reading the blob into memory and close the underlying stream) as well deferred reading (no content is read until the reference is consumed during compilation). MetadataFileReference only supports deferred reading.

     Lifetime of MetadataFileReference is non-deterministic, the underlying file is locked until no references exist and we GC the metadata.  On the other hand, it is possible to construct MetadataImageReference in such a way that allows controlling the underlying resources deterministically.

     Remove MetadataFileReference, use MetadataImageReference instead.

     2) Lifetime management
     AssemblyMetadata and ModuleMetadata objects hold on resources and implement IDisposable. When using MetadataFileReference constructors and some MetadataImageReference constructors to create references the underlying metadata objects are created implicitly and the user doesn’t have a way to explicitly dispose them.

     Make MetadataImageReference constructors internal and instead add factory method GetReference on AssemblyMetadata/ModuleMetadata. The usage pattern is:

     using (var metadata = AssemblyMetadata.CreateFromXxx(…))
     {
         var compilation = CSharpCompilation.Create(syntaxTrees, new[] { metadata.GetReference() });
         …
     }

     In addition the shelveset makes MetadataImageReference internal and adds the following convenience APIs, that are not the most efficient but are very convenient, easy to discover and safe to use for customers that don’t wanna explicitly manage the lifetime of metadata objects. (changeset 1345987)

made compiler error message to not include namespaces in most cases. this should make parsing error message a bit easier. (changeset 1334448)

Delete test associated with "Won't Fix" bug (effort to keep it running would yield net negative returns) (changeset 1331314)

* Fix 879811: Do not suppress ambiguity errors if they are caused be the same nested type imported through several using static directives with different type arguments.
* Fix typos in comments, corrupted characters due to incorrect source encoding, remove unnecessary casts, namespace qualifiers, type arguments and using directives. (changeset 1326357)

This is a part of porting C# synthesized refactoring work where the names of long-lived variables follow a naming pattern that allows us to reverse-engineer the SynthesizedLocalKind value from the variable name. Especially in this change, we give a synthesized variable an explicit name based on its SynthesizedLocalKind at emit time, not at local symbol creation time. (changeset 1324862)

Changes emit for synthetic methods backing lambda expressions to include dummy "this" parameter to match the number of parameters in delegate "Invoke" method.

When implementing static lambdas (those that do not have closures) C# has a choice of emitting an open or a closed delegate. In the latter case we can just enclose null and not use it in the method.
It appears that in a case of closed delegate, Invoke dispatch is considerably cheaper - no need to left-shift the arguments to adjust for missing "this".

== Example:

Consider code like the following

Func<int, int, int> adder = (x, y) => x + y;

Since the lambda does not need to enclose anything, we can implement it in two ways.

• Open delegate implementation (current)

        public static int Add(int x, int y)
        {
            return x + y;
        }

        Func<int, int, int> adderOpen = cls1.Add;

• Closed delegate implementation (also works and seems better)

        // does not really need to be an extension when in synthetic code
        public static int Add(this object dummy, int x, int y)
        {
            return x + y;
        }

        // enclose null
        Func<int, int, int> adderClosed = ((object)null).Add;

Crude experiments confirm that invoking adderClosed indeed costs noticeably less than adderOpen. (about 30% less in common scenarios like adding two ints)

This change adjusts codegen for static lambdas to use closed delegates.

 (changeset 1285058)