This reverts commit 92ff3f8d.

This reverts commit b03e8478.

The flag name is "IOperation". Register opeartion actions and calling
SemanticModel.GetOperation while the feature is disabled will throw an
InvalidOperationException. Also log a non-fatal-watson when
SemanticModel.GetOperation crashes.

Code cracker recently added an analyzer that accidentally reports diagnostics with a location in a syntax tree outside of the current compilation. We were not handling this case gracefully and causing VS to crash. Code cracker fixed their analyzer and released an updated package. This change guards against such cases by ignoring such diagnostics and reporting an analyzer exception diagnostic about invalid diagnostic.

Fixes #7173

Handle in-memory assemblies correctly in ScriptOptions.AddReference and when adding reference to the host object

Fixes #949

Report a diagnostic if an analyzer reports a diagnostic with an invalid ID (has non-alphanumeric characters).

We execute the analyzer driver's initialization and core analysis tasks on a background thread. Any exceptions from the driver itself (not the analyzer callbacks, we already report diagnostics for those) were getting swallowed and analyzer execution also skipped silently. See #2980 (comment) for an example.

We now report an exception diagnostic for analyzer driver crash (with the complete exception trace), so that the user knows what happened and we can diagnose the bug when the issue is reported.

Fixes #3005

Changes include:

1. Enhance CompilationWithAnalyzers to allow computing analyzer diagnostics for a specific tree/span within a compilation and/or for a subset of analyzers. Implementation ensures no duplicate analysis by tracking partial analysis state and caching the reported analyzer diagnostics.

2. Overview of the new APIs added to CompilationWithAnalyzers:
    1. GetAnalyzerSyntaxDiagnostics(tree, analyzers, ct)
        1. Analogous to SyntaxTree.GetDiagnostics(ct)
        2. Gets analyzer diagnostics reported by executing syntax tree actions on the given tree.
    2. GetAnalyzerSemanticDiagnostics(semanticModel, spanOpt, analyzers, ct)
        1. Analogous to SemanticModel.GetDiagnostics(spanOpt, ct)
        2. Gets analyzer diagnostics reported by executing rest of the non-compilation actions on the given tree span.
    3. GetAnalyzerCompilationDiagnostics(analyzers, ct)
        1. Gets rest of the analyzer diagnostics which are reported by either of the following means:
            1. Compilation actions (and compilation end actions)
            2. Non-compilation actions reporting diagnostics on different tree: Executing a symbol action on a symbol definition in a tree, can report diagnostic on its partial definition in some other tree.

3. Simplify IDE analyzer driver by switching it to using the new CompilationWithAnalyzers APIs for analyzer diagnostic computation. Both the IDE and compiler drivers now use the compilation event queue model for driving analysis.

Fixes internal bug 1093063: 'csc2.exe'/ 'vbc2.exe' will ICE (exit with Code 1) when trying to report errors on localized installs

User scenario: Create a default VB/C# project on a localized OS, introduce some errors/warnings and build the project from the command line through msbuild.
Expected: Compiler diagnostics show up in the build output.
Actual: No diagnostics are displayed, and msbuild exits with code 1.

Fix: MSBuild tasks have a specific parsing logic to look for non-localized diagnostic severity strings such as "error" and "warning" in the compiler output to detect errors and warnings. Our diagnostic formatter was localizing these severity strings, causing the msbuild parsing to fail on localized OS. Fix is to match the Dev12 compiler behavior by not localizing the severity strings.

Testing: Added regression tests + existing tests.

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 the complete exception stack trace to the description field of analyzer exception diagnostics. This will ensure that the stack trace can be viewed in the error list by expanding the diagnostic message.

Fixes #1444

XML schema validation is not available on core clr and hence can't be in this
particular layer of the compiler.  Instead moving to the manual validation of the
small amount of data required for this rule.

closes #1687

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 #252 : If an analyzer reports a diagnostic with an unsupported diagnostic ID, i.e. no descriptor returned by SupportedDiagnostics has that ID, then throw an ArgumentException in ReportDiagnostic method. This exception would be turned into an analyzer diagnostic by the driver and reported back to the analyzer host.
Also fix a few tests that were reporting diagnostics with unsupported ID!

1) Don't crash command line builds when reporting analyzer diagnostics. Reporting analyzer diagnostics may involve invoking user code for LocalizableString message, which may throw while finding resources or for other unknown reasons. We catch exceptions from these callbacks and report a diagnostic with the inner exception message.
I verified that this addressed the crash seen in #271 and #813 and we started seeing this new info diagnostic.

2) Workaround for #271: The underlying cause of the crash is that our assembly resolver/CLR is unable to fallback to the main assembly for resources and ends up looking for the satellite resource assembly. We had seen this crash quite a while back, but it went away and this seems to have come up again. Workaround, as applied back then, is to mark the analyzer assembly with NeutralResourcesLanguageAttribute.
I verified that adding this attribute to our core analyzer assemblies caused the resource to be correctly found and we don't even see the exception diagnostic from (1) above, but instead the actual diagnostic reported by the analyzer.

This is necessary to correctly reject invalid assembly references and to match the native compiler. (changeset 1396814)

***NO_CI***
 (changeset 1392938)

Allow PE and PDB streams to be arbitrary writable streams. If the specified stream doesn't fulfill implementation specific requirements of the PE/PDB writer use an intermediate in-memory stream and write its content to the user specified one at the end of emit.

Fixes #349.
 (changeset 1388751)

Fix for bug 1072380: Audit public APIs to make sure we have the right degree of validation for parameters

Add argument validation for public APIs in diagnostic analyzer driver, code fix and refactoring context. (changeset 1367094)

IDE and compiler analyzer driver refactoring to internalize a bunch of public APIs in the compiler driver.

Bunch of analyzer related types (actions, scope, etc.) were forced to be public as the IDE driver was doing the core analyzer action execution. The big change here that enabled internalizing was to move all the core analyzer action execution down to the compiler layer by adding Execute*Actions public APIs on compiler analyzer driver for all action kinds (analogous to the current ExecuteSyntaxNodeActions and ExecuteCodeBlockActions APIs). Major API internalization changes are:

1) Make HostAnalysisScope and its subytpes internal in the compiler layer and remove the public API AnalyzerDriver.GetSessionAnalysisScope. Session analysis scope essentially maintains a map from analyzers to their registered actions. By explicitly storing this map on the IDE driver, we don't need the shared session scope.

2) Make constructors of all the analyzer context types internal and make all the analysis scope types internal too as IDE driver doesn't need them anymore.

3) Make AnalyzerAction and all it's subtypes internal in compiler layer. This was made possible by both the above changes.

4) The only remaining public type now (apart from DiagnosticAnalyzer and context types) is AnalyzerActions, which is essentially a bag of registered actions. All it's properties that exposed the analyzer actions have been made internal. (changeset 1366505)

Fix for bug 1046530: Should the strings in Microsoft.CodeAnalysis.DiagnosticFormatter.GetMessagePrefix be localized?

Localize the diagnostic severity in DiagnosticFormatter.GetMessagePrefix. (changeset 1355104)

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)