- 02 9月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
1) Use IDynamicInvocationExpression for VB late bound invocation and C# dynamic invocation. 2) Use IDynamicIndexerAccessExpression for C# dynamic indexer access; not used in VB. 3) Remove IDynamicObjectCreationExpression.MemberName property. 4) Add extension methods on IHasDynamicArgumentExpression to get optional argument name and ref kind for an argument at a given index.
-
- 25 8月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
-
- 24 8月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
Fixes #20114 and #20122
-
- 21 8月, 2017 1 次提交
-
-
由 Dustin Campbell 提交于
-
- 19 8月, 2017 6 次提交
-
-
由 Andy Gocke 提交于
-
由 Andy Gocke 提交于
-
由 Manish Vasani 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 18 8月, 2017 5 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 Ivan Basov 提交于
* parameter refness update in local funcitons/lambda should be caught as an edit * handling empty accessors and bodies * removing unused internal parameter
-
由 CyrusNajmabadi 提交于
-
由 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.
-
由 Fredric Silberberg 提交于
-
- 17 8月, 2017 8 次提交
-
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
由 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
-
由 Manish Vasani 提交于
A customer trace on recent 15.3 release shows that `Microsoft.CodeAnalysis.CSharp!Binder.IsAccessibleHelper` is taking up large amount of CPU stacks for LookupSymbols(name) calls from IDE analyzers. This change optimizes the performance of this code path by adding a name check before doing accessibilty checks.
-
- 16 8月, 2017 17 次提交
-
-
由 Heejae Chang 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Jason Malinowski 提交于
Everything still builds if I delete these, so they must be fine.
-
由 Fredric Silberberg 提交于
-
由 Fredric Silberberg 提交于
-
由 Heejae Chang 提交于
#1. made persisted storage exclusive to 1 process. like before, second VS with same solution will not use persisted storage. #2, tweaked sqlite to share cache between connections like esent. #3, made VS and OOP to use different db files (we can make them to share if we want to, but for now, nobody requires it so we create 2 different db) .. made OOP mock to enable persisted service.
-
由 CyrusNajmabadi 提交于
-
由 Fredric Silberberg 提交于
-
由 Tomáš Matoušek 提交于
-
由 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
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Fredric Silberberg 提交于
-