Fixes #5072.
Also fixed some issues around LangVersion handling, which were found along the way.

Add a new command line compiler switch "/reportanalyzer" to report analyzer execution times. Output is grouped by analyzer assemblies and is displayed in descending order of execution times.

NOTE: We do not display the total build time or the ratios between build time and analyzer execution time as the the actual wall clock time for analyzer execution is likely lesser due to multithreaded analyzer execution.

Add a new switch '/errorlog:' to VB and C# command line compilers to log all the compiler diagnostics into a log file.
Add command line parsing tests and error log content validation tests.

Fixes #1029

While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.

After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.

Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key

Adds target type conversions for VB interpolated string expressions to allow them to be converted to IFormattable or FormattableString instances. (changeset 1403673)

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)

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)

Prevent memory starvation or a compiler crash due to an OutOfMemoryException caused by constant folding for deeply nested constant string concatenation.

To prevent memory starvation, especially inside a 64  bit process, we keep track of lengths of all (to a certain degree) constant string values stored in the bound expression tree that we are building and report an error as soon as the combined length of all of them is about to be greater than Int32.MaxValue. The length of the resulting constant value might still be shorter than Int32.MaxValue.

***NO_CI***
 (changeset 1395692)

1) Add VB and C# compiler tests to verify that all configurable compiler diagnostics (non-errors) that show up in the ruleset editor have a non-null and non-empty Title and Category.
2) Commented out some more unused diagnostic IDs in both compilers that were found through these tests.
3) Add title resource strings for hidden and info compiler diagnostics. These are configurable and show up in the ruleset editor. (changeset 1390346)

Initial compiler support for VB string interpolation. Does not include target typing or any IDE support. (changeset 1390282)

This adds a per-rule Title for all C# and VB compiler warnings that have message strings.  These Titles will show up in the ruleset editor.

This also includes Descriptions that show up upon expansion for a set of high-hit C# warnings.  I added Descriptions for high-hit warnings per MSDN.  The work is still pending to add the equivalent VB warning Descriptions.

The principle was to basically restate the base Message string without its fill-ins as the Title, swapping in general words such as "method" and "type".  Often, just removing the fill-ins and quotes was enough, as the surrounding context already said what the code element was.  Sometimes the message needed to be reworded a bit.  I also left out any further clauses (such as "Consider ..."), except for shortened versions necessary to disambiguate similar warnings.  For now, I'm leaving such clauses in the messages themselves, using Description for longer-form explanations - we can see if we get feedback there.

This should be the content work needed to ship the ruleset editor without blank titles.  There was one key bug remaining (now filed) where rules kept around solely to make previous /nowarns and #pragmas happy still show up in the ruleset editor.

Remaining work:
* Descriptions for VB compiler warnings
* Titles/Descriptions for C#/VB compiler errors
* Categories for VB/C# compiler warnings/errors (changeset 1387213)

Due to CLR bug 1094313 the added members can't be referenced from another assembly. For now we report a rude edit if we detect a MemberRef or TypeRef to a symbol added during debugging.
 (changeset 1384081)

Also includes VB implementation
 (changeset 1383936)

***NO_CI***
 (changeset 1382915)

     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)

***NO_CI***
 (changeset 1356181)

     Moves options that were previously on CompilationOptions but were not used until emit phase to EmitOptions: fileAlignment, baseAddress, highEntropyVirtualAddressSpace, subsystemVersion, runtimeMetadataVersion. They hold on values written to various PE headers. We can now easily add other similar PE flags to EmitOptions, which is a common customer request, without affecting code that works with compilation options in other layers (workspaces, project system, etc.).

     Removes EmitMeadataOnly method and instead adds a MetadataOnly flag to EmitOptions. Removes MetadataOnlyEmitOptions - they were not used and can now be easily added as bools to EmitOptions.

     Moves pdbFilePath and outputName from parameters of Emit to EmitOptions.

IDE: remove tracking of options that were moved to EmitOptions, since the IDE doesn't care about options that don't affect compilation. (changeset 1348623)

 (changeset 1346054)

***NO_CI***
 (changeset 1341617)

     The feature is conditional on "experimental" language version. (changeset 1339783)

There are a number of design and implementation issues with the "Warning as Error" and "Warning treated as error" prefixes shown on C# and VB warnings that have been promoted to errors:

1.) The prefix is redundant. The command line already prefixes the issue with "error" if it is being treated as an error, and so the additional prefix is not needed. For example:

Before:
         error CS0168: Warning as Error: The variable 'x' is declared but never used
After
         error CS0168: The variable 'x' is declared but never used

Inside VS, the Error List icons display the same information.

2.) The prefix redirects the user's focus from the issue itself to the fact that is has been promoted from an warning to an error. It is more noise than help.

3.) The VB implementation is just weird.

C# simply adds the prefix to the message and leaves everything else alone.

VB, however, outputs two errors when treating a warning as an error. One is the original issue with the original error code and message, just as an error. The second is an error with a special "Warning treated as error" error and the prefixed message. However, this extra error is only issued once for a group of issues, even if multiple issues in that group should be promoted to errors.

4.) C# and VB have completely different implementations for the same feature. In VB, the core compiler layer handles adding the prefix and generating the second error. In C#, each compiler host (csc.exe, vbcscompiler.exe, VS, etc.) is responsible for adding the prefix to the message. This makes it difficult for other compiler hosts to report errors the same way csc.exe/vbc.exe do, and difficult to merge errors from multiple sources (such as happens when running a build from within VS).

After some discussion, it was decided that the low (or non-existent) value provided by this "feature" did not warrant the implementation complexity, and it should be removed. (changeset 1337219)

- Ensure we can build and run tests when current system locale isn’t English.
- Move CSC/VBC help strings to resources so that they can be localized.
 (changeset 1330638)

- Syntax tree
- Parsing
- Initial binding
- Naive lowering, resulting IL might be inefficient or, in some cases, might be incorrect with respect to preserving side effects in the target.
 (changeset 1329866)

Stop validating warning ids specified in /nowarn and /warnaserror and allow custom diagnostics to be specified via both (in both VB and C#).

Also, start reporting custom info diagnostics on the command line. The compiler generated info diagnostics for unused imports have now been changed to 'hidden' so that we don't start seeing them all over the place during builds. (changeset 1315557)

Implements end-to-end support for #Enable / #Disable (warning suppression) directives in VB. Also enables light-bulb based suppression for warnings (and custom diagnostics) in VB.

Implements following design changes proposed at last week's meeting -

a. #Enable and #Disable directives now only allow diagnostic ids specified as identifiers (e.g. #Disable Warning BC42024). Numeric and string literals (e.g. #Disable Warning 42024, "BC42024") are no longer supported.

b. Identifiers that are used to specify enabled / suppressed diagnostic ids are case insensitive (i.e. #Disable Warning BC42024 and #Disable Warning bc42024 are equivalent).

TODO: Following changes proposed at last week's meeting are NYI -

c. Allow custom diagnostic ids to be specified via /nowarn and /warnaserror and stop validating whether ids specified via these switches are legal compiler warnings.

d. Implement corresponding changes for C# pragma directives and C# command line compiler. (changeset 1292950)

Implements parser support for the new #Enable / #Disable feature in VB along with changes required for lighting up following IDE features: classification, keyword recommender, formatting.

Speclet - http://roslyn.codeplex.com/discussions/543476. Feature is equivalent to the #pragma warning feature in C#.

ToDo: Changes to actually suppress / unsupress diagnostics in the compiler are NYI. IDE support for the new directives should be mostly complete except for keyword highlighting which I intend to look into in a subsequent change. (changeset 1283171)