- 07 2月, 2017 1 次提交
-
-
由 Jonathon Marolf 提交于
this change prevents an error on RC.3
-
- 05 2月, 2017 1 次提交
-
-
由 Heejae Chang 提交于
changed all caller to call JsonRpc.StartListener once all states are set
-
- 04 2月, 2017 6 次提交
-
-
由 Heejae Chang 提交于
-
由 Neal Gafter 提交于
-
由 Jonathon Marolf 提交于
Gather better info when AddDeclarationConflictsAsync crashes
-
由 Jonathon Marolf 提交于
Avoid deadlocks when unloading unloading multitargeted Asp.NET projects, or .NET Standard (CPS) Projects (directly or via Solution close) referencing Shared Projects
-
由 Jonathon Marolf 提交于
capture document on findtoken crash in linked files
-
由 Julien Couvreur 提交于
-
- 03 2月, 2017 7 次提交
-
-
由 Jonathon Marolf 提交于
We are seeing reports of Visual Studio crashing in FindToken with argument out of range exceptions. It appears that this is causes by linked files being of differing lengths. This change captures the original and linked documents on the stack so we can better understand what is happening.
-
由 CyrusNajmabadi 提交于
Fix crash in roundtripping a symbol that references a LocalFunction's TypeParameter.
-
由 Jason Malinowski 提交于
Fix VisualStudioWorkspace thread affinity and defer creation
-
由 David Poeschl 提交于
Avoid deadlocks when unloading .NET Standard Projects (directly or via Solution close) referencing Shared Projects Fixes https://github.com/dotnet/roslyn/issues/14479 The problem here is that unloading projects takes a serialization lock, which can cause Shared Project IVsHierarchys to notify us that their context hierarchy has changed. In response to this, we try to set the new active context document for open files, which also tries to take the serialization lock, and we deadlock. For .NET Framework Projects that reference Shared Projects, two things prevent deadlocks when projects unload. During solution close, any Shared Projects are disconnected before the projects start to unload, so no IVsHierarchy events are fired. During a single project unload, we receive notification of the context hierarchy change before the project is unloaded, avoiding any IVsHierarchy events if we tell the shared hierarchy to set its context hierarchy to what it already is. Neither of these behaviors are safe to rely on with .NET Standard projects, so we have to prevent the deadlock ourselves. We do this by remembering if we're already in the serialization lock due to project unload, and then not take the lock to update document contexts if so (but continuing to lock if it's not during a project unload).
-
由 Jared Parsons 提交于
Move to new VS SDK build tools
-
由 Omar Tawfik 提交于
Add tests to ref return error codes
-
- 02 2月, 2017 6 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 CyrusNajmabadi 提交于
-
由 Jason Malinowski 提交于
When we create a ForegroundThreadAffinitizedObject, it captures what is believed to be the foreground thread at that point. That can be bad if it hasn't been initialized, as the background thread might be the assumed initialization. As a terrible, slimy hack, we'll just defer this until the foreground asserts are happening. The first might slip through but later requests would then blow up.
-
由 Jason Malinowski 提交于
The request for the document tracking service could need the UI thread, which is bad if we're creating the VisualStudioWorkspace on a background thread. Since there's no reason to do caching until we have something to cache, we can defer this work.
-
由 Omar Tawfik 提交于
-
- 01 2月, 2017 12 次提交
-
-
由 Jason Malinowski 提交于
My earlier refactoring here replaced a call that was doing an 'as' cast under the covers with a hard cast. It turns out in devenv /build this service is a different type that doesn't actually implement the same interfaces, so the distinction was important. This restores the old behavior.
-
由 Jason Malinowski 提交于
This causes problems if we're spinning up a workspace on a background thread. Let's defer until actually having to fetch metadata, which we don't do in most cases anyways.
-
由 Julien Couvreur 提交于
-
由 Omar Tawfik 提交于
-
由 David Poeschl 提交于
Inline Rename: Prevent crash when source control dialogs show
-
由 Omar Tawfik 提交于
Added tests for VB implicitly defined tuples
-
由 Heejae Chang 提交于
added max file limit
-
由 David Poeschl 提交于
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=227513 InlineRenameSession.ApplyReplacementText is called in response to buffer changes. In response to these changes, we want to (1) kick off some background work to calculate the new ConflictResolutionTask, (2) propagate the new replacementText to all buffers on the UI thread, and then (3) apply the results of the ConflictResolutionTask on the UI thread once they're ready. Prior to this change, steps (1) and (3) were always done together, in sequence, regardless of how (2) was progressing. Since the replacementText propagation started synchronously and stayed on the UI thread, this usually meant that the application of the results of the ConflictResolutionTask would have to wait until the replacementText propagation completed (because it would wait for the UI thread to be available). This worked great, most of the time. But, if the propagation of the replacementText causes a buffer change in a source controlled document and "Prompt for Checkout" is enabled, then a modal dialog to checkout files appears. Then, the UI thread pumps and allows more work to be scheduled there. Our ConflictResolutionTask could finish calculating conflicts and the application of these conflicts could be scheduled on the UI thread while a dialog is still up (and we are still propagating the replacementText). It would then try to manipulate the undo stack and apply edits to buffers. Since we still have an open undo transaction from the replacementText propagation, the attempt to manipulate the undo stack would crash. This change splits the kicking off of the ConflictResolutionTask and the application of the replacements it computes into separately callable methods that aren't automatically chained together. In some cases they can be called in sequence, emulating the old behavior. But when a text buffer edit triggers ApplyReplacementText, we first kick off the ConflictResolutionTask, then propagate the new replacementText, and *then*, once the replacementText is fully propagated (including the handling of any source control modal dialogs), we finally apply the results of the ConflictResolutionTask on the UI thread. This does not guarantee that *no* reentrancy will ever happen in Inline Rename, but it gets rid of the biggest, obvious culprit. Completely safeguarding would require a larger change, and I think this approach is the best one given our current RTM escrow timeline, and it will fix the problem for the vast majority of users encountering this problem.
-
由 David Poeschl 提交于
Remove RC3 builds from the README
-
由 Heejae Chang 提交于
-
由 David Poeschl 提交于
-
由 Ty Overby 提交于
-
- 31 1月, 2017 4 次提交
-
-
由 Heejae Chang 提交于
this is added so that we can reduce chance of OOM when user added massive size text file to solution. current default max is 100MB. but user can override it through hidden reg key if they want to. if such file is added, FileTextLoader will throw InvalidDataException and Workspace will raise Workspace Failed event. in VS host case, we will show the failed event in output windows. made it to use test option service since option is mutable workspace state which affects all other tests.
-
由 Jason Malinowski 提交于
It's still obsolete, but adding it breaks people trying to compile with warn as error enabled.
-
由 Jason Malinowski 提交于
-
由 Neal Gafter 提交于
Fixes #14202
-
- 30 1月, 2017 1 次提交
-
-
由 Omar Tawfik 提交于
-
- 28 1月, 2017 2 次提交
-
-
由 Vladimir Sadov 提交于
Some more automated tests and test cleanup for the PR#16659
-
由 Ty Overby 提交于
* add end to end stack depth test * add comment explaining test * switch to verify diagnostics * turn parallel build off * check pointer size in addition to debug/release
-