- 16 11月, 2017 3 次提交
-
-
由 AlekseyTs 提交于
Related to #22548 and #22229.
-
由 Manish Vasani 提交于
Do not expose operation nodes for BoundRangeVariables in C# query exp…
-
由 AlekseyTs 提交于
Related to #22548 and #22229. There are several issues with IOperation tree when it comes to conversions applied to tuple literals: 1. When conversion is explicitly specified in code, it is translated to conversions on individual elements of the literal and these BoundConversion nodes are also marked as explicitly specified in code (which makes sense). However, the syntax associated with a BoundConversion node on top of an element matches the syntax of the element (which also makes sense). The problem is that both the conversion node and the element appear as “explicit” in IOperation tree, which violates one of the tree invariants – at most one “explicit” node for a given syntax node. 2. When a tuple literal is converted, compiler creates a BoundConvertedTupleLiteral node, which has the target tuple type as its Type, but the BoundConversion node on top of the BoundConvertedTupleLiteral captures conversion information (kind, etc.) for conversion From tuple’s natural type to the target type. So, often, we end up with both nodes having The same Type, but the conversion says it is not an identity conversion. This shape helps SemanticModel to provide accurate information about types and conversions, but the IOperation tree looks very confusing. 3. When conversion is explicitly specified in code, the BoundConversion node from the previous item is marked as explicitly specified in code, but it shares syntax node with BoundConvertedTupleLiteral. Both nodes appear as “explicit” in IOperation tree, which violates the same invariant. 4. When conversion is explicitly specified in code, compiler adds yet another explicit Identity conversion on top of the BoundConversion node from the previous item. It is needed for proper SemanticModel behavior. Even when it uses different syntax, the IOperation tree looks very confusing, there are two conversions on top of each other and it is not clear why intermediate conversion node is needed. In order to address all these issue the following changes are made to IOperation factory: - If conversion node is associated with the same syntax as its operand, the conversion is marked as isImplicit. - If Type of BoundConvertedTupleLiteral matches the Type of BoundConversion node on top of it the conversion node is not added to the IOperation tree. Instead a new property is added to ITupleOperation interface, called NaturalType. The property exposes the natural type of the tuple literal and makes it easy for consumers to figure out if a conversion from a natural type of a tuple literal took place. - If Type of BoundConvertedTupleLiteral doesn’t match the Type of BoundConversion node on top of it and there is an identity conversion node on top of the BoundConversion node, the intermediate conversion node is not added to the IOperation tree, its conversion information is used for the top-most conversion node (instead of saying that it is identity).
-
- 15 11月, 2017 10 次提交
-
-
由 Ashley Hauck 提交于
Reduce the use of the preprocessor
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Ashley Hauck 提交于
-
由 Fred Silberberg 提交于
Address followup nits from IOp prs.
-
由 Ashley Hauck 提交于
Replace Windows RID multitargeting with singular form
-
由 Manish Vasani 提交于
-
由 Ashley Hauck 提交于
-
由 Andy Gocke 提交于
-
由 Ashley Hauck 提交于
-
- 14 11月, 2017 8 次提交
-
-
由 Sam Harwell 提交于
Do not offer 'var' if it would cause overload resolution issues.
-
由 elijah6 提交于
* Separating warning messages for constant filter expression * Deal with try-catch with finally block and add test
-
由 Ashley Hauck 提交于
Use all RIDs on all platforms
-
由 Jason Malinowski 提交于
Add the Roslyn version string into Help > About
-
由 Sam Harwell 提交于
Disable 'use local function' in a few important language cases.
-
由 Andy Gocke 提交于
RunCore previously had a mix of diagnostic reporting methods including lists of Diagnostics, lists of DiagnosticInfos, ConcurrentQueues of Diagnostics, and just printing things directly to the console. This commit tries to simplify things by moving to using Diagnostics and DiagnosticBags wherever possible in the compile+emit phase of RunCore.
-
由 Ashley Hauck 提交于
-
由 Ashley Hauck 提交于
-
- 13 11月, 2017 7 次提交
-
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 CyrusNajmabadi 提交于
Simplify check.
-
由 Sam Harwell 提交于
Fixed field name generation in Introduce constant field refactoring
-
由 Sam Harwell 提交于
-
由 Sam Harwell 提交于
Fixed NRE in IntroduceVariableCodeRefactoringProvider refactoring
-
由 Sam Harwell 提交于
Insert documentation comments in the face of trim_whitespace
-
- 12 11月, 2017 8 次提交
-
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Cyrus Najmabadi 提交于
-
由 Victor Z 提交于
-
由 Sam Harwell 提交于
-
- 11 11月, 2017 4 次提交
-
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Jason Malinowski 提交于
This shows our informational version in Help > About instead of a useless ProductID GUID. Fixes dotnet/roslyn#17038.
-
由 Tomáš Matoušek 提交于
scripting hosts: print the submission stack trace only to the console
-