- 13 2月, 2016 5 次提交
-
-
由 AlekseyTs 提交于
Ensure DeclarationTreeBuilder.GetModifiers doesn't throw on unexpected tokens that have errors.
-
由 AlekseyTs 提交于
Handle default parameter values for event accessors in CreateBinderForNodeAndUsage.
-
由 CyrusNajmabadi 提交于
Prevent NaN from slipping into .Measure calls. Fixes #8514
-
由 Jared Parsons 提交于
Normalize paths when generating pipe names
-
由 Jared Parsons 提交于
Harden determinism job
-
- 12 2月, 2016 35 次提交
-
-
由 Dustin Campbell 提交于
Fix Code Model race for real this time
-
由 Tomáš Matoušek 提交于
Misc renames and minor cleanup
-
由 Tomáš Matoušek 提交于
Add CompilationOutputFiles test helper.
-
由 Dustin Campbell 提交于
I thought I'd fixed this subtle race with PR #8607. After all, the check-in tests were passing and it passed locally on my machine. However, it was still failing consistently on the build server. Finally, I noticed that the only test passes that were failing were on x86 *Release* (insert sound of forehead being smacked). After compiling Release, I could reproduce the problem locally. It turns out that this was a race with GC. In a previous fix, when adding an element to FileCodeModel's element cache, we would first check to see if the element was already in the cache. If it was in the cache, we'd remove it before adding it. However, the test to see if the element was in the cache called `CleanableWeakComHandleTable.TryGetValue(TKey key, out TValue value)`, which would only return true if `key` was in the cache and `value` was not set to null. In essence, it's defined like so: ```C# public bool TryGetValue(TKey key, out TValue value) { this.AssertIsForeground(); WeakComHandle<TValue, TValue> handle; if (_table.TryGetValue(key, out handle)) { value = handle.ComAggregateObject; return value != null; } value = null; return false; } ``` However, when running in Release, the GC can run a bit more aggresively and `handle.ComAggregatedObject` (a weak reference) could easily be null. The fix is to add a simpler `CleanableWeakComHandleTable.ContainsKey(TKey key)` and use that instead. ```C# public bool ContainsKey(TKey key) { this.AssertIsForeground(); return _table.ContainsKey(key); } ```
-
由 CyrusNajmabadi 提交于
Enable Glyph's on code actions.
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
由 Andrew Casey 提交于
Don't call GetGenericsArguments unless IsGeneric is true
-
由 Jared Parsons 提交于
It turns out APIs are very inconsistent in whether they leave a trailing directory separator on path names. This caused the client and server code to generate different pipe names for the same file location. Hence VbcsCompiler -shutdown was failing because it used the wrong pipe name. Fix this by normalizing path names.
-
由 Jared Parsons 提交于
This hardens the determinism job: - Properly terminates build processes on exit - Creates a zip file of all information needed for investigation on failure
-
由 David Kean 提交于
Test projects automatically inherit app.config
-
由 Dustin Campbell 提交于
Fix race in Code Model cache
-
由 Tomas Matousek 提交于
-
由 AlekseyTs 提交于
Fixes #8400.
-
由 David Kean 提交于
Add "*" on enter pressed within comment blocks
-
由 Andrew Casey 提交于
-
由 Jared Parsons 提交于
-
由 AlekseyTs 提交于
Fixes #8401.
-
由 Tomáš Matoušek 提交于
Update to SRM 1.2.0-rc3-23811
-
由 Neal Gafter 提交于
Document "Better Betterness" for C# 6 and the compat fix
-
由 Dustin Campbell 提交于
This addresses a race condition introduced in our per-FileCodeModel cache of code elements by PR #8424. In that change, we attempted to handle the situation where a code model element is about to be inserted in the cache with the same "node key" is an element that is already in the cache. This can happen in normal operation if a Code Model consumer were to programmatically add a variable, delete the variable's underlying text and immediately add the same variable again. The original fix would conditionally remove the old element from the cache if its "node key" could not be resolved in the FileCodeModel's current syntax tree. Then it would add the new element with the same "node key" to the cache. However, this appears to not be deterministic and would sometimes result in a collision. This PR changes the policy to **unconditionally** remove the old element from the cache if one exists before adding the new element. Because the purpose of the cache is to return existing elements when accessing various collections (e.g. "Members"), it makes sense that the latest element would be returned. In addition, because the "node key" referenced by the old element has become valid again, accessing properties on the old element will continue to work.
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
由 Andrew Casey 提交于
-
由 Andrew Casey 提交于
Fixes #8452
-
由 Balaji Krishnan 提交于
More test coverage for delegate invoke with conditional access
-
由 Charles Stoner 提交于
Ignore synthesized delegates in AnonymousTypeManager.GetAnonymousTypeMap
-
由 Dustin Campbell 提交于
Add more diagnostic information to better understand what's happening if TestAddAndRemoveViaTextChangeManyTimes fails
-
由 Artur Spychaj 提交于
Improve selection handling when sending to interactive
-
由 Charles Stoner 提交于
-
由 Charles Stoner 提交于
-