Fixes sequence points for infinite for loop: for(;;) {}. We used to create a sequence point that spans over the entire ForStatement node. Instead this sequence point should be hidden, there is no user code in for (;;) so we don't step on it.

Fixes EnC active statement mapping for parts of ForStatement - initialization/declaration, condition and incrementing expressions are now considered significant nodes in statement tree.  (changeset 1303974)

For every conditional branch that consumes a value of an expression that might contain calls to user code and that jumps across user code with sequence points, we need to store the value into a synthesized named local, emit stloc and ldloc and place a hidden sequence point on the ldloc instruction. Furthermore, the synthesized local variable has to be associated with the statement syntax whose lowering produces the conditional branch so that EnC infrastructure can map the local variable defined for the branch to the previous generation.

In essence this is what’s going on:

[|if (F())|]
{ … true … }
else
{ … false … }

IL:
call F()
stloc $value
<-- hidden sequence point -->
ldloc $value
brfalse label_false
<-- sequence point for “{“ of true-block -->
… true …
br label_end
label_false:
<-- sequence point for “{“of false-block -->
… false …
label_end:

When the call to F() returns after an update has been performed on the caller the code execution continues in the old version of the caller body until a special remapping breakpoint is hit. These breakpoints are put on all sequence points of the method. If we didn’t put the hidden sequence point in front of the conditional branch the execution would continue in the old code until another sequence point is hit. Such a sequence point can be arbitrary (suppose e.g. that the else block of the if statement is deleted by an edit). The debugger only knows how to map IP of active statements in the old IL to an IP in the new IL, not arbitrary sequence points. By inserting the hidden sequence point we force the mapping to be performed at well-defined point that we can map to the new method body.

The presence of the hidden sequence point then implies the need of storing the value of the if-statement condition to a long-lived local and reloading it back right after the sequence point. The store will happen before the IP is remapped and the load will happen in the new frame. The synthesized local must be allocated the same slot in the new frame so that its value is transferred from the old frame to the new frame.

Fixes bug 927151: Edit and Continue breaks If statements while inside the conditional method.

This change also includes an update to the test infrastructure to
1) make it easier to update failing test that checks for an expected IL
If a VerifyIL fails it synthesizes a temp file containing the unit test source and prints out a link that launches a diff tool (using ROSLYN_DIFFTOOL environment variable).
2) to be able to directly test correspondence of sequence points to IL.
VerifyIL has now an optional argument “sequencePoints”. When specified the printed IL will contain marks that designate presence of sequence points at IL offsets. “-“ for regular sequence point, “~” for hidden sequence points.
I have updated some tests that are supposed to validate correspondence of sequence points to IL instructions to use this new format.  (changeset 1299447)

To support EnC well the compiler needs to carefully distinguish between long-lived and short-lived synthesized variables. Long-lived variables may cross sequence points and thus need to be mapped the the corresponding variables in the previous generation when emitting EnC deltas. Short-lived local variables shall never cross sequence points.

This change revisits helpers that create synthesized variables and assigns each synthesized variable a SynthesizedLocalKind. Negative kind values are reserved for short-lived variables, positive values for long-lived variables.

The change removed the option to give a synthesized variable an explicit name. The names of the variables are assigned at code-gen time based on their SynthesizedLocalKind. This is to enforce that the names of long-lived variables follow a naming pattern that allows use to reverse-engineer the SynthesizedLocalKind value from the variable name.

Also renames DebugInformationKind.PDBOnly to DebugInformationKind.PdbOnly to follow .NET naming guidelines.
 (changeset 1293017)

For constructors, we used to get a span for the whole declaration as in Dev12:

          [|public MyCtorName(params int[] values): base()|]

, which are not aligned with how we set the corresponding breakpoint span. This shelveset updates sequence points in a similar way breakpoints are spanned. See more in BreakpointSpans.cs. For the above example, we are going to have the following span:

          public MyCtorName(params int[] values): [|base()|]
 (changeset 1291401)

The compiler generates a local variable to store an exception object in synthesized try-catch handler of an async method. It also used to generate a hidden sequence point in the middle of it's lifespan. This sequence point is unnecessary. Once removed the variable name can also be removed. (changeset 1287817)

An expression body is an alternative to a block on certain members (properties, methods, operators, and conversions), which uses the lambda => to define an expression as the body of the member. (changeset 1281748)

Support breakpoints on Autoprop initializer and add the corresponding sequence points. (changeset 1281420)

Converts non-portable Compilation.Emits that accepts file paths to extension methods and removes SyntaxFactory.ParseFile.

Cleans up Emit methods on CSharpCompilation and VisualBasicCompilation.
Reorders parameters of Emit methods so that cancellation token is the last one to follow a common convention. (changeset 1271389)

An expression-bodied property is a property with an expression instead of accessors, i.e. syntax st. a property P written as

... type P { get { return e; } }

is equivalent to

... type P => e;

This feature is experimental and keyed on the Experimental LanguageVersion. (changeset 1263330)

The sequence point used to be on the "using" keyword while the break point spans around both "using" keyword and the expression. Here, we adjust sequence points to be aligned with break points. Also, we update unittests in a way that the markup can be used to identify a specific span which is verified. (changeset 1261135)

Stores Encoding on SourceText so that we can always calculate checksum of the underlying binary data, even if the SourceText wasn’t created from a Stream.

Adds WithRootAndOptions and WithFilePath methods to SyntaxTree and implements them for all subclasses. I decided to merge WithRoot and WithOptions to a single method WithRootAndOptions since setting one without the other doesn't make much sense (the options should correspond to the root node).

Propagates the Encoding throughout workspaces and services.
Refactors recoverable syntax trees so that they can implement With* methods.

Allow encoding on SourceText to be unspecified (null) and report an emit diagnostic when attempting to emit debug information for a syntax tree that is backed by encoding-less source text. If user creates a syntax tree from a string they previously read from a file and then try to emit debuggable compilation with such tree the original encoding of the file might not match the default UTF8 (they might different by presence of BOM, which is quite subtle). To avoid confusion we don't set UTF8 encoding by default. Instead we report the diagnostic and the user needs to explicitly provide an encoding to the syntax tree factory method.

Avoid leaking DecoderFallbackException out of EncodedStringText.Create. Throw InvalidDataException instead to reduce the amount of exceptions that the caller needs to deal with.

Also moves HasSameText extension method from Services to SourceText and optimizes the comparison for the case we the SHA1 checksums are available.
 (changeset 1260412)

Currently the async state machine is a struct. Struct is better for performance (no allocation) but prevents us to modify local variables in the async method in EnC. The CLR doesn't support adding fields to a struct. (changeset 1252494)

Rolling back changeset that switched async state machine to a class. Investigating some issues.  (changeset 1252130)

 Currently the async state machine is a struct. Struct is better for performance (no allocation) but prevents us to modify local variables in the async method in EnC. The CLR doesn't support adding fields to a struct.

     This change switches the state machine to a class when emitting unoptimized debug code (/debug:full /optimize-). It keeps it struct otherwise. (changeset 1251785)

We make the compilers (both C# and VB) deterministic (identical inputs cause identical outputs). In theory this may make distributed and incremental builds much easier to implement. It will also allow one to determine easily if any API has changed or not by simply generating a reference assembly and checking if it is identical to the previous one.

Two things needed to change:
(1) The timestamp in the header is replaced with 0 (which is specifically allowed by the spec)
(2) The module version ID Guid (Mvid) is computed by hashing the contents of the generated assembly (with zero
      where the Mvid will go for the purposes of computing the hash)

The name of the "private implementation details" class no longer includes the Mvid.

In order to simplify things, I removed the parameter from a few emit APIs where the caller provides the Guid for the Mvid. It turns out that nobody nowhere used it. So when emitting in the normal way, we don't know the Mvid ahead of time. For edit-and-continue, however, we always reuse the Mvid for the original assembly as before.

I implemented this assuming that everyone wants this new behavior. Some may worry that perhaps some unknown tool depends on the presence of the timestamp. I'd prefer to push it this way and see if anything breaks, because it will be simpler for it to just always work this way rather than having an option to turn it on and off. Also, I look forward to seeing if there is any performance impact due to running SHA1 over the whole in-memory stream. I suspect it will be unmeasurably small.

By the way, strong name signing happens after this is done, so there is no need to worry that a signature will introduce nondeterminism in the mvid. The strong name signature includes mvid in the data it signs. See Compilation.SerializeToPeStream to see the sequence. (changeset 1235486)

Convert PdbWritingException and PermissionSetFileReadException exceptions to diagnostics when emitting an EnC delta.
Adds test that verify we catch the exception using a mock sym writer.

Also removes a dependency on FileStream from SerializeToPeStream.
 (changeset 1231460)

Adding CultureContext to Roslyn test utilities to enable compiler tests to be culture agnostic (changeset 1223204)

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)

* the code that was injecting indirect returns had unreliable logic when detecting the appropriate block.
We could end up injecting return in the middle of the method body and the rest would get dropped as unreachable.

* added debug visualization support for BasicBlock and ILBuilder.
We used to have visualization here shared with IL dumping, but it gradually migrated out to the test utilities.
It has been a while since we had to fix a bug in codegen, but now, I realize that it is fairly hard to debug this kind of issues without visualizers.
 (changeset 1209393)

Replaces FileResolver with 2 types that are portable and implement reference resolution for specific feature. The goal is to have 3 resolvers total - one for each kind of reference to artifact that the source may contain
1) MetadataReferenceResolver
Resolves #r directive values.
2) SourceReferenceResolver
Resolves source references and normalizes source paths. Used by #line, #pragma checksum and PDB paths (and #load in script files, which is not implemented yet).
3) XmlReferenceResolver
Resolves references to XML documents in <include> and PermissionSet(File = "...")

Each resolver is also a provider of the resolved content. Currently that's not true for MetadataReferenceResolver, we have a separate MetadataReferenceProvider. I'll follow up with a change that merges these two.

In addition to the above resolvers CompilationOptions still have AssemblyIdentityComparer and StrongNameProvider. These remain unchanged.

The non-portable part of the compiler provides a file resolver for each reference resolver:
1) MetadataFileReferenceResolver (to be renamed to MetadataFileResolver)
2) SourceFileResolver
3) XmlFileResolver

these resolvers implement csc/vbc behaviors.

Default CompilationOptions don't have any resolvers. Thus the features that are dependent on these resolvers won't work and a diagnostic is reported. (changeset 1208519)