- 19 1月, 2019 2 次提交
-
-
由 Jason Malinowski 提交于
The actual work was a nested type called .Snapshot, which everything was using directly. The renames in here are: - VisualStudioMetadataReference.Snapshot to VisualStudioPortableExecutableReference - The _provider field in .Snapshot to _referenceManager - VisualStudioMetadataReferenceManager.CreateMetadataReferenceSnapshot to just .CreateMetadataReference, since it's always a snapshot.
-
由 Jason Malinowski 提交于
The FileChangeWatcherProvider has to do some magic so we can hand out a FileChangeWatcher that fetches the IVsFileChangeEx from the shell, but not in a way that implicitly risks any marshal back to the UI thread in a way that might deadlock. The odd bit was we were doing some of that initialization in the VisualStudioWorkspace constructor itself which didn't really make sense. While I'm here, we can also remove the hack that was working around a shell bug where we might deadlock if we called into the async service provider from a background thread.
-
- 17 1月, 2019 2 次提交
-
-
由 Jared Parsons 提交于
Async-streams: Recognize MoveNextAsync that returns an awaitable
-
由 Jared Parsons 提交于
Fix NullReferenceException in LocalRewriter.MakeConversionNode
-
- 16 1月, 2019 9 次提交
-
-
由 Jason Malinowski 提交于
Fix regression where renaming a CodeElement didn't update node keys
-
由 Jason Malinowski 提交于
In a larger refactoring I had commented some code out in NodeKeyValidation.AddProject. This meant that when we did a refactor rename of a CodeElement, we wouldn't end up updating node keys for all the existing CodeElements out there. The expectation is CodeElements are still valid. Uncommenting the code and bringing it back inline with the current design makes everything work again. Fixes dotnet/roslyn#31735.
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
We were creating them directly, but this meant that there was no proper way to enumerate all of them since we weren't providing a ProjectCodeModelFactory. This brings the tests slightly more inline with "real" Visual Studio.
-
由 Rikki Gibson 提交于
-
由 Rikki Gibson 提交于
-
由 Rikki Gibson 提交于
-
由 Rikki Gibson 提交于
-
由 Rikki Gibson 提交于
-
- 15 1月, 2019 4 次提交
-
-
由 Jason Malinowski 提交于
Finish the project context implementation for the free-threaded project system shims
-
由 Jared Parsons 提交于
Disable a few tests on Mono
-
由 Jared Parsons 提交于
This disables a few tests that have recently turned up as flaky on Mono. - DestructorOverridesNonDestructor: this test is pretty specific to the JIT / GC implementation. It doesn't run on CoreClr already due to the subtle differences. Shouldn't have been run on Mono in the first place. - TestCallMethodsWithLeastCustomModifiers: there appears to be a runtime race condition around how overloads that differ by only `modopt` elements are resolved. Follow up issue https://github.com/mono/mono/issues/12422
-
由 Joey Robichaud 提交于
-
- 12 1月, 2019 14 次提交
-
-
由 Jason Malinowski 提交于
This is an optimization that if you have 20 or 30 files open, and only one of them came from a shared asset project, and that project is changing context, we don't need to refresh all of the rest. Since the refreshing is on the UI thread, we want that to be quick.
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
The protected method took the state lock, got the container, let go of the state lock, and then acquired all of the locks. This isn't really safe anyways because once all the locks were released the document could have been closed and disconnected entirely.
-
由 Jason Malinowski 提交于
The pattern matches all our other On* methods.
-
由 Jason Malinowski 提交于
This was being applied at the caller, a few lines before the actual call. Now it's obvious what it's doing.
-
由 Jason Malinowski 提交于
This was setting a magic thread local property which tracked if we were currently unloading a project, and if so avoided taking a lock when the context changed. This was somewhat self-inflicted because we were trying to change project contexts in the Visual Studio shell during the middle of unload. We're not doing that anymore, and removing this also allows us to allow project removal off the UI thread.
-
由 Jason Malinowski 提交于
This behavior causes all sorts of problems: removing a file (which can now happen on a background thread) then tries to call into all sorts of UI-affinitized APIs which are unavailable there. Practically, there's no reason we must do this anyways: if you do remove a file in one context, we'll update our internal structures to point to a new context. There's no real harm in that being temporarily out of sync: either we'll pick the right context at random and the user won't notice, or if we pick the wrong one, they can select the one they want and everything will be updated again. Fixes dotnet/roslyn#31019.
-
由 Jason Malinowski 提交于
The comment implied that custom handling could be done by overriding this but no such overriding is being done, and trying to do so would be very sketchy.
-
由 Jason Malinowski 提交于
Because the code wasn't finished, we were leaking IVsHierarchies since we had no cleanup logic. We hold onto the IVsHierarchies per document cookie (although we do share the watchers), so if we close a file we only unhook from the correct IVsHierarchies rather than having to re- look at everything.
-
由 Jason Malinowski 提交于
We already had this inside of VisualStudioRuleSetManager, and we need it for more things too. For now all the locking semantics are being kept identical.
-
由 Jason Malinowski 提交于
The basic mental here is to determine a context for a file, we start with the Running Document Table and grab the IVsHierarchy for that file. We then chase it through shared projects until we arrive at final IVsHierarchy. This should be the IVsHierarchy we were given for the project. In the case of multitargeting projects, there's one last hop where we fetch a VSHPROPID_ActiveIntellisenseProjectContext that just returns the project name instead of a IVsHierarchy. If you squint you could imagine that as if it returned the IVsHierarchy for that project except we don't have unique ones. To set the context, we start with the project and walk those IVsHierarchy pointers backwards. At each step we can do an operation to figure out which IVsHierarchy needs its pointer updated, and we point it to build the chain, moving back to the IVsHierarchy that will end up in the Running Document Table. This is (still) leaking IVsHierarchies that we subscribe to, and that will be fixed next.
-
由 Sam Harwell 提交于
Avoid navigating to message severity items unless requested
-
由 AlekseyTs 提交于
Closes #31862.
-
- 11 1月, 2019 5 次提交
-
-
由 Heejae Chang 提交于
1. we never disposed tag aggregator leaking all taggers ever created on the buffer involved in contained document 2. we hold on to taggers not related to our buffer but ones that are related to other buffers. for example, our subject buffer is actually subject buffer which involves template C# buffer + html buffer where portion of html buffer are mapped to the subject buffer. that we end up holding on to all html taggers.
-
由 Sam Harwell 提交于
Fixes an occasional failure in the ErrorList test.
-
由 Sam Harwell 提交于
Fix null check combined with nullable bool test
-
由 Julien Couvreur 提交于
-
由 AlekseyTs 提交于
-
- 10 1月, 2019 4 次提交
-
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-