- 18 8月, 2017 1 次提交
-
-
由 AlekseyTs 提交于
Fix crash in VisualBasic.Binder.MemberLookup.AddLookupSymbolsInfoInTypeParameter when it is called with Cref TypeParameter. (#21586) Fixes https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems?id=410932. The fix mimics the way C# compiler handles Cref TypeParameters in the similar API.
-
- 17 8月, 2017 1 次提交
-
-
由 Andy Gocke 提交于
Perform synthesis of closure methods in an early pass before visitation, meaning we no longer need to do a second visitation of the tree to lower local functions. The baselines have been changed because we now do closure id and synthessis in order of closure visitation, rather than bound node visitation. Closure visitation visits all the closures in a given scope, then recurs into nested scopes, while BoundNode visitation treats closures as scopes themselves, so nested closures are visited before closures declared in the same scope. Fixes https://github.com/dotnet/roslyn/projects/26#card-3753331
-
- 16 8月, 2017 7 次提交
-
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Andy Gocke 提交于
In the introduction of the new 'this' optimization routine, one of the things which was changed was to treat 'this' more like a formal parameter of the method, as opposed to a variable living in an implicit, higher scope. This has some advantages in simplicity for analysis, but created a problem when it came to proxies. The current analysis builds the proxy list by walking the tree and finding all captured variables and adding them to the proxy dictionary keyed by the original variable symbol. For instance, if a local variable is captured to a field, during rewriting it will be added to the proxy list as (original symbol, hoisted field). Since most symbols are only ever captured to a single replacement field, this usually works fine -- all proxies can exist side-by-side in the proxy list since there is no intersection. However, this is not true for captured environment pointers. When a new environment is introduced, a local will be created to point to that environment. That local may itself be captured by nested variables, creating a linked list from nested scopes to parent scope. Most notably, *multiple* nested environments may capture the *same* environment pointer in *different* hoisted fields. This means that the proxies dictionary cannot hold all mappings at once, since the mapping for a given captured environment pointer will depend on the current scope. The current code actually accounts for this already by adding a captured environment pointer to the proxy list on a nested scope's introduction, and removing it upon leaving that scope. By changing 'this' to be treated like a formal parameter, I circumvented this logic, introducing a bug. When two scopes tried to capture the 'this' pointer, the compiler crashed due to trying to add two mappings to the same key. This change fixes this problem by treating the 'this' parameter like an environment pointer for the purposes of capturing and hoisting. It's possible that we want to treat it like a formal parameter, but if so it's probably better to treat all captured environment pointers the same way and introduce a scope-aware notion of proxies, rather than having a global dictionary. Fixes #21506
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Charles Stoner 提交于
are marked not usable in C#7
-
- 15 8月, 2017 6 次提交
-
-
由 Ashley Hauck 提交于
-
由 Ashley Hauck 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
- 14 8月, 2017 1 次提交
-
-
由 Ashley Hauck 提交于
-
- 12 8月, 2017 7 次提交
-
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Ashley Hauck 提交于
-
由 Fredric Silberberg 提交于
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
-
由 Ashley Hauck 提交于
-
- 11 8月, 2017 6 次提交
-
-
由 Andy Gocke 提交于
Currently, the lambda rewriter has an early optimization pass in analysis that tries to find all local functions that only capture 'this' and remove references to local functions that do the same. There are two problems with this approach: 1) Generally, removing information from the tree is a bad idea because it hurts further analysis passes that may have needed that information. 2) The optimization strategy itself is very tricky and has a number of complex corner cases. This has lead to bugs, for example #19033. This PR deletes the current method and adds a new optimization routine at the end of the analysis, operating on assigned scopes and environments rather than removing captured variable analysis. The new optimization is as follows: if we end up with an environment containing only 'this', the environment can be removed, all containing methods can be moved to the top-level type, and all environments which capture the 'this' environment can instead directly capture the 'this' parameter. This produces almost the same results as the previous optimization, but is easier to validate as an algebraic equivalence. The baseline changes come from the new optimization being less aggressive about moving functions which only capture 'this' to the top level. This appears to be a wash -- some codegen gets slightly better, some gets slightly worse. Fixes #19033 Fixes #20577
-
由 Tomáš Matoušek 提交于
* Compare lines instead of using AssertXml when validating PDBs. AssertXml doesn't validate ordering. * Reorder expected PDB XML nodes to match actual order * Update to the latest Microsoft.DiaSymReader.* packages. * Enable embedding sources to Windows PDBs
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
由 Fredric Silberberg 提交于
-
由 jinuz420 提交于
-
- 10 8月, 2017 1 次提交
-
-
由 Fredric Silberberg 提交于
-
- 09 8月, 2017 5 次提交
-
-
由 Petr Onderka 提交于
Merged on behalf of @svick Thanks for the contribution!
-
由 Gen Lu 提交于
-
由 Tomáš Matoušek 提交于
* Clean up Concord exception utilities * Avoid dependency on IL stream in EnC local slot mapping * Fix lambda EnC
-
由 Gen Lu 提交于
-
由 Fredric Silberberg 提交于
-
- 08 8月, 2017 4 次提交
-
-
由 Jinu 提交于
* Tagging VB/C# Ioperation tests * Fix the Wrong Tagging
-
由 Andy Gocke 提交于
The frame creation pass now considers scope of captured variable introduction instead of closure creation, so the ordering can change if two or more nested functions access variables 'outside-in', e.g. ```csharp { int x = 0; { int y = 0; int L1() => y; { int z = 0; int L2() => x; } } } ``` If we visit closures in-order in the previous example, we create frames for L1, then L2. If we visit captured variables scopes, however, we visit `x` (captured by L2), then `y` (captued by L1).
-
由 Andy Gocke 提交于
This is part of the effort to move as much logic from LambdaRewriter into Analysis as possible. The more logic there is in the Rewriter, the more difficult it is to find calculation problems until the last possible moment, and it's also very difficult to calculate useful information for later analysis passes, like the final debug and closure IDs for each environment.
-
由 Julien Couvreur 提交于
-
- 06 8月, 2017 1 次提交
-
-
由 Fredric Silberberg 提交于
-