- 07 5月, 2014 13 次提交
-
-
由 chandera 提交于
-
由 chandera 提交于
-
由 AlekseyTs 提交于
Enable assignment to a declaration expression. Fixes https://roslyn.codeplex.com/workitem/18. This is a port of https://roslyn.codeplex.com/SourceControl/changeset/0d51dfd01a7ff479cdae0bb90837dfa3770e6562. (changeset 1250584)
-
由 AlekseyTs 提交于
Report ERR_MethodArgCantBeRefAny for “out var” declarations without initializers. This is a port of https://roslyn.codeplex.com/SourceControl/changeset/4b562c0061233f3e3a76de510ecd68b2d37fa1b1. (changeset 1250556)
-
由 AlekseyTs 提交于
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)
-
由 AlekseyTs 提交于
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)
-
由 TomasMatousek 提交于
Factor generating of custom debug information to a separate class. Remove mutable state from PEWriter related to custom debug info generation. (changeset 1250467)
-
由 AlekseyTs 提交于
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)
-
由 shyamn 提交于
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)
-
由 srivatsn 提交于
-
由 YingP99 提交于
Bug 687246: fix NumberStyles overlooked in previous checkin (thanks Chuck found out) (changeset 1250362)
-
由 YingP99 提交于
Bug fix (923303): check null parameter and throw for API - GetAnnotations(...) (changeset 1250335)
-
由 nslottow 提交于
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)
-
- 06 5月, 2014 5 次提交
-
-
由 AlekseyTs 提交于
Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)
-
由 TomasMatousek 提交于
Use ImmutableArray instead if IEnumerable. (changeset 1249786)
-
由 AlekseyTs 提交于
Migrated state of “Primary Constructors” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/af3db25146a74523fbb2cf11ef00ddec6c0c3690. (changeset 1249690)
-
由 TomasMatousek 提交于
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)
-
由 VSadov 提交于
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)
-
- 05 5月, 2014 1 次提交
-
-
由 AlekseyTs 提交于
Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)
-
- 04 5月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
Use ImmutableArray instead if IEnumerable. (changeset 1249786)
-
- 03 5月, 2014 10 次提交
-
-
由 AlekseyTs 提交于
Migrated state of “Primary Constructors” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/af3db25146a74523fbb2cf11ef00ddec6c0c3690. (changeset 1249690)
-
由 TomasMatousek 提交于
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)
-
由 VSadov 提交于
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)
-
由 ChuckStoner 提交于
EnC: MethodImpl entries should only be added if the implementing method was added (changeset 1249535)
-
由 kayleh 提交于
-
由 mattwar 提交于
-
由 YingP99 提交于
Bug fix (687246, 687 373): globalization - pass proper culture information when calling some TryParse() and IndexOf() methods (changeset 1249342)
-
由 AlekseyTs 提交于
-
由 AlekseyTs 提交于
-
由 kayleh 提交于
This avoids unnecessary calls to AssemblyQualifiedName. (changeset 1248550)
-
- 02 5月, 2014 6 次提交
-
-
由 mattwar 提交于
-
由 MuradT 提交于
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)
-
由 AlekseyTs 提交于
Perform method group conversion validation when an instance of a delegate type is passed as an argument to a delegate constructor. (changeset 1248441)
-
由 acasey 提交于
-
由 AlekseyTs 提交于
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)
-
由 TomasMatousek 提交于
Renames Emit.Context to EmitContext and removes unnecessary namespace qualifications of EmitContext and Cci types. (changeset 1248215)
-
- 01 5月, 2014 3 次提交
-
-
由 TomasMatousek 提交于
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)
-
由 acasey 提交于
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)
-
由 ChuckStoner 提交于
-
- 30 4月, 2014 1 次提交
-
-
由 ChuckStoner 提交于
-