- 17 7月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 15 7月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 11 7月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 07 7月, 2015 2 次提交
-
-
由 Evan Hauck 提交于
-
由 Charles Stoner 提交于
-
- 03 7月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 02 7月, 2015 2 次提交
-
-
由 Evan Hauck 提交于
-
由 Jared Parsons 提交于
Fell out of our normal cadence for this during the push for RTM. Now that we had a bit more breathing room getting us back on track here.
-
- 23 6月, 2015 1 次提交
-
-
由 Evan Hauck 提交于
-
- 20 6月, 2015 2 次提交
-
-
由 Evan Hauck 提交于
Definite assignment, generic iterators, symbol display, and parser fixes
-
由 Evan Hauck 提交于
-
- 09 6月, 2015 5 次提交
-
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
由 Evan Hauck 提交于
-
- 16 5月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 14 5月, 2015 2 次提交
-
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
-
- 13 5月, 2015 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #2549
-
- 07 5月, 2015 1 次提交
-
-
由 Wonseok Chae 提交于
This happens since setting next statement skips the closure initialization, which marks as hidden sequence point. In this PR, we emit a regular sequence point instead of a hidden sequence point to closure initialization whenever necessary, so IP move won't skip closure initialization.
-
- 03 5月, 2015 1 次提交
-
-
由 bkoelman 提交于
-
- 29 4月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 16 4月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 15 4月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 08 4月, 2015 1 次提交
-
-
由 Kevin Halverson 提交于
Variables may have been captured by lambdas in the original method or in the expression, and we need to preserve the existing values of those variables in the expression. This requires rewriting the variables in the expression based on the closure classes from both the original method and the expression, and generating a preamble that copies values into the expression closure classes. Consider the original method: ``` Shared Sub M() Dim x, y, z as Integer ... F(Function() x + y) End Sub ``` and the expression in the EE: "F(Function() x + z)". The expression is first rewritten using the closure class and the local `<1>` from the original method: F(Function() `<1>`.x + z) Then lambda rewriting introduces a new closure class that includes the locals `<1>` and z, and a corresponding local `<2>`: F(Function() `<2>`.`<1>`.x + `<2>`.z) And a preamble is added to initialize the fields of `<2>`: ``` <2> = New <>c__DisplayClass0() <2>.<1> = <1> <2>.z = z ```
-
- 07 4月, 2015 1 次提交
-
-
由 Charles Stoner 提交于
-
- 05 4月, 2015 1 次提交
-
-
由 Andrew Casey 提交于
(cherry picked from commit 505501bc38905a4389994d4452d56300e36c01db)
-
- 25 3月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 17 3月, 2015 2 次提交
-
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
Categorize synthesized query lambdas Make sure SynthesizedLambdaSymbol and BoundQeuryLambda has the same syntax
-
- 06 3月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 01 2月, 2015 1 次提交
-
-
由 beep boop 提交于
Background: As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation. https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style The coding style transition is automated using a Roslyn based rewrite tool: https://github.com/dotnet/codeformatter This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens. Note: this is a soft style requirement. There are no build errors that come from this change. (changeset 1408227)
-
- 31 1月, 2015 1 次提交
-
-
由 TomasMatousek 提交于
1) Change MethdCompiler.BindMethodBody to associate correct syntax with BoundBlocks it creates when binding constructor with constructor initializer call (two bound blocks are created – outer one defines a closure scope for constructor parameters, the inner one defines a closure scope for variables in the body). 2) Introduce MethodDebugId – a method ordinal and generation ordinal pair 3) Introduce LamdbaDebugInfo and ClosureDebugInfo to represent information (syntax offset) we use to figure out how to map lambdas and closures to the previous generation. 4) Adds a new PDB CDI record (#7) to store lambda and closure debug info. 5) Generalizes CalculateLocalSyntaxOffset to handle positions in field/property initializers and constructor initializers. Use it to calculate syntax offsets of lambdas and closure scopes. (TODO: rename CalculateLocalSyntaxOffset to CalculateSyntaxOffset). 6) Replace lambda and scope ordinal dispenser integers with array builders that collect LambdaDebugInfo and ClosureDebugInfo. 7) Use TryGet- pattern for all VariableSlotAllocator APIs. 8) Implements mapping of lambda method and display class names to previous generation via VariableSlotAllocator. (changeset 1407240)
-
- 28 1月, 2015 1 次提交
-
-
由 TomasMatousek 提交于
The compiler emits catch-all handler to all async methods. In case of async void methods we also emit the offset of the catch handler to PDB, so that the debugger can pretend that exceptions thrown by the async method are unhandled. Otherwise they are lost. Currently the compiler emits wrong offset, so the debugger is completely confused and displays "no source location" when such exception occurs. The fix is to remove a synthesized "nop" instruction that was incorrectly used to track the catch handler IL offset. Instead mark the synthesized BoundCatchHandler node by a flag and create the IL marker in the CodeGen when emitting instructions for such bound node. Affects both C# and VB. Fixes bug 1114809. (changeset 1405564)
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 2 次提交
-
-
由 RoslynTeam 提交于
-
由 TomasMatousek 提交于
1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique. 2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead. 3) Removes GenerateTempNumber from TypeCompilationState. Combination of method ordinal and other indices is used to make generated names unique: - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name. - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method). - The same for fields caching lambdas. - Delegate relaxation stubs and their closures have a separate numbering and are distinguished from regular lambdas/closures, since they are immutable and EnC doesn't need to map them across generations. - Late-bound AddressOf operator oddly creates real closure and is thus not considered a delegate relaxation for the purposes of synthesized naming. - Properties generated to override inherited WithEvent properties are assigned ids in the source order of Handles clauses. In order to guarantee uniqueness of the names added during EnC include generation ordinal in synthesized names wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation. (changeset 1395267)
-
- 09 1月, 2015 2 次提交
-
-
由 TomasMatousek 提交于
Currently we include a method ordinal to the name of a synthesized member produced during lowering of the method. When a method is added during EnC in the middle of existing members the ordinal is not enough to avoid name conflicts with the previously emitted synthesized members. In order to guarantee uniqueness of the names we now include generation ordinal in synthesized names as well, wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation. An alternative would be to find the highest existing ordinal and start indexing EnC members from there. Such approach would probably work but including the generation number is much simpler and imposes less constraints on the EnC compilation. In addition to including the generic ordinal this changeset also fixes a couple of bugs that were previously masked or we haven't had coverage of the scenarios: - the EnC changeset calculation was not properly handling additions of synthesized members into existing synthesized classes. - SymbolMatcher didn't map local variable types forward correctly for variables of synthesized types. - SymbolMatcher didn't handle generic static lambda display classes with generic. Currently we create generic parameters for these classes via alpha renaming of the type parameters of the top-level generic method. VB is constructing fresh generic parameters, which seems a better approach. I'll leave changing this to a follow-up changeset. As a byproduct of this change we can now enable editing of methods containing dynamic operations. It just works now! Each update of such method creates a new set of dynamic sites. We don't attempt to reuse existing sites. It's little bit wasteful but it also avoids the need of invalidating the call-site caches. (changeset 1393184)
-
由 TomasMatousek 提交于
Static lambdas in generic methods are emitted on per-method display class. Include method ordinal into its name to make it unique. The previous change to synthesized name numbering introduced a regression - if two generic methods of the same arity contained static lambdas the resulting assembly had duplicate type names. This change addresses that case. (changeset 1391470)
-