Report name collision for “out var” declarations without initializers. Fixes http://roslyn.codeplex.com/workitem/42. This is a port of https://roslyn.codeplex.com/SourceControl/changeset/c8c365cfa05594119a2bf4d269fbf23b2ae51d33. (changeset 1250509)

Improve CS0523 error message for backing fields of primary constructor parameters. This is a port of https://roslyn.codeplex.com/SourceControl/changeset/2e28a89593fe4941209c87215855e5ae08775da2. (changeset 1250498)

Factor generating of custom debug information to a separate class. Remove mutable state from PEWriter related to custom debug info generation. (changeset 1250467)

Report an error if an argument list is provided for an implemented interface. Fixes https://roslyn.codeplex.com/workitem/4. This is a port of https://roslyn.codeplex.com/SourceControl/changeset/f930b49714dc268a0e9df96d213d5516634a6450. (changeset 1250419)

interface I
{
static void M(this object o);
}

Result:
(3,17): error CS0106: The modifier 'static' is not valid for this item
(3,17): error CS1105: Extension methods must be static

Expected:
(3,17): error CS0106: The modifier 'static' is not valid for this item
(3,17): error CS1106: Extension method must be defined in a non-generic static class

The fix was simple - I simply switched the order in which the above extension method errors are reported. However, this has a small side-effect in that it changes the error reporting for the following case. The change seems acceptable (i.e. user would anyways have hit the new error that we report now as soon as they fixed the error that the old compiler was reporting in this case). I've fixed up the couple of tests that were validating the old error for this case.

class C
{
void M(this object o) { }
}

Old (Native as well as Roslyn):
Test.cs(3,10): error CS1105: Extension method must be static

New:
Test.cs(1,7): error CS1106: Extension method must be defined in a non-generic static class (changeset 1250408)

Bug 687246: fix NumberStyles overlooked in previous checkin (thanks Chuck found out) (changeset 1250362)

Bug fix (923303): check null parameter and throw for API - GetAnnotations(...) (changeset 1250335)

The analyzers for CA1309, CA2213, CA2214, CA2200 were all calling GetSymbolInfo earlier and/or more often than they needed to and were slowing down analysis.  This change adds checks before the offending calls to GetSymbolInfo.  This also corrects the behavior of the CA2214 analyzer, which was previously producing warnings for all virtual methods called from within a constructor, not just for virtual methods defined in the class containing the constructor. (changeset 1250296)

Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)

Use ImmutableArray instead if IEnumerable. (changeset 1249786)

Migrated state of “Primary Constructors” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/af3db25146a74523fbb2cf11ef00ddec6c0c3690. (changeset 1249690)

In C# lowering of async method stored the state machine type on SourceMethodSymbol so it can later be used when emitting synthesized attributes of the method. This may cause issues when emitting the same compilation twice with different options that affect the state machine type.
     Instead we should store the state machine type to the current PEModuleBuilder. Rather then actually storing it there and adding a dependency on PEModuleBuilder to the attribute generation this change introduces ModuleCompilationState (similar to TypeCompilationState) and threads that one.
     This type is designed to be mutable during compilation (lowering) and immutable during emit. The idea is that all data currently stored in PEModuleBuilder that are produced during compilation and only read in emit could be moved there. Only emit specific data would remain on PEModuleBuilder.

     Also refactors Compilation.Compile to remove some duplication and make it cleaner.
 (changeset 1249664)

 Change Description:

     Implementation of conditional access operators ( ?. and ?[] )

     The grammar roughly looks like:

     expr ::= | ...
              | expr ? tail

     tail ::= | tailopt . id
     tail ::= | tailopt .$ id                        <---   this is NYI in this change
              | tailopt [ expr-args ]
              | tail ( expr-args )

     Note that the tail isn’t optional for invocation: there is no ?(…) operator.

     Interesting implementation points:

     == Parsing/syntax

     Syntax tree is right associative – it has the same topology as in the grammar. However I did not create special variants for all the kinds of syntax that could be produced by the parsing of the tail of accessors.
     I just use regular syntax nodes with exception of the topmost node that is the conditional access operator itself and the lower-leftmost node that textually starts the accessor tail.

     The root node looks like –

     ConditionalAccessExpression
     {
        ExpressionSyntax Expression;
        SyntaxToken OperatorToken;                  // always “?”
        ExpressionSyntax WhenNotNull;              // by analogy with conditional expression which uses WhenTrue
     }

     WhenNotNull is an ExpressionSyntax that represent the sequence of postfix operations conditionally applied to the Expression. These are regular InvocationExpressions, MemberAccesses, ElementAcesses – whatever postfix operators we have.

     The only special part about WhenNotNull is that the low-leftmost expression child is one of 2 special “binding” nodes – MemberBindingExpression, ElementBindingExpression.

     Binding expressions are entities which can start the chain of WhenNotNull . Textually they look like  -  “ .SimpleName“ ,  “[argList]” or “$Name” (when $ accessor is supported).
     Note that there is no InvocationBinding, since we do not allow () to start the chain of applications – you cannot do “a?(arg)”.
     The binding expression syntaxes are basically versions of corresponding member/element/dollar access expressions without receivers.

     R?.a.b(x).c

     Would parse as

         ConditionalAccess
       /         |         \
     R           ?          MemberAccess
                                 /    |   \
                       Invocation     .     c
                      /           \
                MemberAccess       ArgList{( x )}
               /        |    \
     MemberBinding      .      b
         |      \
         .       a

     The advantage of using regular syntax nodes on the right side is that semantical analysis “just works”.  Naturally, because of the topology, the API cannot ask nonsensical questions like - what is the type of subexpression “R?.a.b” ?
     Since “R?.a.b” is not a subexpression, there is no way to ask such question.
     It is however possible to interrogate member accesses – they are just regular member accesses (in both syntax and bound trees) so they naturally know their types etc…

     == Binding

     Binding of the tree above is fairly simple – I only had to add binding support for the left-lowermost binding nodes. And what comes out is really just regular access expressions with placeholder receiver.
     I cannot refer to the actual receiver since we are not evaluating it again.

     In terms of schema - Bound tree actually needed even fewer changes than syntax tree – the bound tree for the above expression is just a regular bound tree. It is isomorphic to the syntax.
     The only new bound nodes are the root BoundConditionalAccess and the left-lowermost placeholder receiver – BoundConditionalReceiver.

         BoundConditionalAccess
          /                  \
     <BoundExpr>         BoundMemberAccess {c}
                              /
                        BoundCall {b}
                       /          \
      BoundMemberAccess {a}        List<Args>{ x }
                    /
     BoundConditionalReceiver

     == Dataflow

     Dataflow considers BoundConditionalReceiver always assigned. However the whole WhenNotNull is reachable conditionally  - i.e. assignedVariables state is forked when going into WhenNotNull.
     “receiver is a const” situation is handled trivially. That is similar to the ?? operator but somewhat inverted.

     == Emit

     There are two ways to emit this :
     - In complex cases (nullables, async, expr trees) we lower the conditional access into a ternary with consequence being rewritten as0is with just BoundConditionalReceiver replaced by a temp for the receiver value.
     - In simple case (all reference types), we do not lower the node, emit of BoundConditionalAccess dups the receiver (thus avoiding an IL temp) , checks it for null and conditionally executes the the access expression.
     BoundConditionalReceiver is handled by emit by not emitting anything since it represents receiver value and that is on the stack already.
 (changeset 1249636)

Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)

Use ImmutableArray instead if IEnumerable. (changeset 1249786)

Migrated state of “Primary Constructors” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/af3db25146a74523fbb2cf11ef00ddec6c0c3690. (changeset 1249690)

In C# lowering of async method stored the state machine type on SourceMethodSymbol so it can later be used when emitting synthesized attributes of the method. This may cause issues when emitting the same compilation twice with different options that affect the state machine type.
     Instead we should store the state machine type to the current PEModuleBuilder. Rather then actually storing it there and adding a dependency on PEModuleBuilder to the attribute generation this change introduces ModuleCompilationState (similar to TypeCompilationState) and threads that one.
     This type is designed to be mutable during compilation (lowering) and immutable during emit. The idea is that all data currently stored in PEModuleBuilder that are produced during compilation and only read in emit could be moved there. Only emit specific data would remain on PEModuleBuilder.

     Also refactors Compilation.Compile to remove some duplication and make it cleaner.
 (changeset 1249664)

 Change Description:

     Implementation of conditional access operators ( ?. and ?[] )

     The grammar roughly looks like:

     expr ::= | ...
              | expr ? tail

     tail ::= | tailopt . id
     tail ::= | tailopt .$ id                        <---   this is NYI in this change
              | tailopt [ expr-args ]
              | tail ( expr-args )

     Note that the tail isn’t optional for invocation: there is no ?(…) operator.

     Interesting implementation points:

     == Parsing/syntax

     Syntax tree is right associative – it has the same topology as in the grammar. However I did not create special variants for all the kinds of syntax that could be produced by the parsing of the tail of accessors.
     I just use regular syntax nodes with exception of the topmost node that is the conditional access operator itself and the lower-leftmost node that textually starts the accessor tail.

     The root node looks like –

     ConditionalAccessExpression
     {
        ExpressionSyntax Expression;
        SyntaxToken OperatorToken;                  // always “?”
        ExpressionSyntax WhenNotNull;              // by analogy with conditional expression which uses WhenTrue
     }

     WhenNotNull is an ExpressionSyntax that represent the sequence of postfix operations conditionally applied to the Expression. These are regular InvocationExpressions, MemberAccesses, ElementAcesses – whatever postfix operators we have.

     The only special part about WhenNotNull is that the low-leftmost expression child is one of 2 special “binding” nodes – MemberBindingExpression, ElementBindingExpression.

     Binding expressions are entities which can start the chain of WhenNotNull . Textually they look like  -  “ .SimpleName“ ,  “[argList]” or “$Name” (when $ accessor is supported).
     Note that there is no InvocationBinding, since we do not allow () to start the chain of applications – you cannot do “a?(arg)”.
     The binding expression syntaxes are basically versions of corresponding member/element/dollar access expressions without receivers.

     R?.a.b(x).c

     Would parse as

         ConditionalAccess
       /         |         \
     R           ?          MemberAccess
                                 /    |   \
                       Invocation     .     c
                      /           \
                MemberAccess       ArgList{( x )}
               /        |    \
     MemberBinding      .      b
         |      \
         .       a

     The advantage of using regular syntax nodes on the right side is that semantical analysis “just works”.  Naturally, because of the topology, the API cannot ask nonsensical questions like - what is the type of subexpression “R?.a.b” ?
     Since “R?.a.b” is not a subexpression, there is no way to ask such question.
     It is however possible to interrogate member accesses – they are just regular member accesses (in both syntax and bound trees) so they naturally know their types etc…

     == Binding

     Binding of the tree above is fairly simple – I only had to add binding support for the left-lowermost binding nodes. And what comes out is really just regular access expressions with placeholder receiver.
     I cannot refer to the actual receiver since we are not evaluating it again.

     In terms of schema - Bound tree actually needed even fewer changes than syntax tree – the bound tree for the above expression is just a regular bound tree. It is isomorphic to the syntax.
     The only new bound nodes are the root BoundConditionalAccess and the left-lowermost placeholder receiver – BoundConditionalReceiver.

         BoundConditionalAccess
          /                  \
     <BoundExpr>         BoundMemberAccess {c}
                              /
                        BoundCall {b}
                       /          \
      BoundMemberAccess {a}        List<Args>{ x }
                    /
     BoundConditionalReceiver

     == Dataflow

     Dataflow considers BoundConditionalReceiver always assigned. However the whole WhenNotNull is reachable conditionally  - i.e. assignedVariables state is forked when going into WhenNotNull.
     “receiver is a const” situation is handled trivially. That is similar to the ?? operator but somewhat inverted.

     == Emit

     There are two ways to emit this :
     - In complex cases (nullables, async, expr trees) we lower the conditional access into a ternary with consequence being rewritten as0is with just BoundConditionalReceiver replaced by a temp for the receiver value.
     - In simple case (all reference types), we do not lower the node, emit of BoundConditionalAccess dups the receiver (thus avoiding an IL temp) , checks it for null and conditionally executes the the access expression.
     BoundConditionalReceiver is handled by emit by not emitting anything since it represents receiver value and that is on the stack already.
 (changeset 1249636)

EnC: MethodImpl entries should only be added if the implementing method was added (changeset 1249535)

Bug fix (687246, 687 373): globalization - pass proper culture information when calling some TryParse() and IndexOf() methods (changeset 1249342)

This avoids unnecessary calls to AssemblyQualifiedName. (changeset 1248550)

This deals with bug 552717: C# IntelliSense: 'case' shouldn't appear in completion list after 'goto '.
It stops showing 'case 0', 'case 1' etc. labels in goto statements inside a switch block. It also stops showing the 'default' *keyword* after such a 'goto'. (The symbol completion provider already shows it in intellisense if it's been defined, and it without this change we'd see two of these).

The compiler still reports some labels with a colon appended to the end for which I've logged bug 937141: Labels in a switch statement have the colon appended to the name of the label, e.g. 'case 0:', 'default:' (changeset 1248486)

Perform method group conversion validation when an instance of a delegate type is passed as an argument to a delegate constructor. (changeset 1248441)

When ArrayInitializerExpression is a local variable/field initializer, GetTypeInfo should return ConvertedType equal to the array type of the symbol being initialized. Fixes #116. (changeset 1248307)

Renames Emit.Context to EmitContext and removes unnecessary namespace qualifications of EmitContext and Cci types. (changeset 1248215)

We need to be more conscious about producing synthesized symbols during lowering in order to enable EnC of method bodies whose lowering produce such symbols (e.g. lambdas, iterators, dynamic sites, etc.).

     This change refactors synthesized symbols in C# so that all symbols produced during lowering phase implement an interface (ISynthesizedMethodBodyImplementationSymbol) that can be used in the emit phase to retrieve information necessary for updating the corresponding metadata entities should they enter EnC.

     I also attempted to somewhat improve and increase consistency of the naming of synthesized symbols involved in this change.

     No new functionality is added by this change. (changeset 1247789)

Crefs ignore inherited members, but I missed a few cases.

1) Binder lookup dropped them, but semantic model lookup (totally separate code path) did not.
2) Base interface members were dropped, but System.Object members were not (except with recovery code during binding). (changeset 1245954)

     Bug (934091)  fix and additional coverage for conflict error messages when conflict between static local and local are defined with the same name

     Additional coverage added to ensure that single diagnostic is generated irrespective of order. (changeset 1242502)

Bug Fix 933719 on diagnostic message to remove term VB Core as its possible to repro without using VB Core.    Change Tests and add additional coverage for command line and Compilation scenarios without VB Core being used.
 (changeset 1241434)

There were issues with the PE headers generated by the compiler when emitting assemblies with no win32 resources (default behavior when you call Compilation.Emit).

If the size of a section is zero, then the relative virtual address should also be zero.  Previously, we would unconditionally set the address of the resource section to the end of the most recently preceding section that contained any data.  This was wrong in and of itself, but it also had the knock-on effect of breaking the logic in PeWriter.WriteRelocSection that is supposed to pad the last section to align with the file alignment boundary. (changeset 1240642)

When warnaserror is set for a project, we set the GeneralDiagnosticOption on CompilationOptions to be error and that turns any diagnostic that doesn't have a specific option set to an error. This means diagnostcs from simplify typename etc. get turned into errors and squiggles everything. The consensus from the diagnostic team meeting was this:
* When doing warn-as-error, don't raise severity for anything *below* warning (info or hidden).
* When doing suppress-all-warnings, don't lower severity for anything *above* warning (error).

Implementing this in C# and VB. Tests will follow.
 (changeset 1239863)