-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge 'dotnet/master' into DefaultInterfaceImplementation #33607
Merged
AlekseyTs
merged 117 commits into
dotnet:features/DefaultInterfaceImplementation
from
AlekseyTs:DefaultInterfaceImplementation
Feb 22, 2019
Merged
Merge 'dotnet/master' into DefaultInterfaceImplementation #33607
AlekseyTs
merged 117 commits into
dotnet:features/DefaultInterfaceImplementation
from
AlekseyTs:DefaultInterfaceImplementation
Feb 22, 2019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…r to use SymbolFinder.OriginalSymbolsMatch. SymbolFinder.OriginalSymbolsMatch has heuristics to determine if types are the same even if coming from a different assembly. This helps in cases where GoToImplementation needs to resolve across projects that get types like System.Threading.Tasks.Task from different assemblies, but are equivalent and fulfill requirements for interface implementation.
The constructor/destructor are heavily thread-affinitized, so let's assert that requirement.
The only set of the property set it false, so it wasn't ever going to do anything.
We have a case where removing a file that's currently part of a code model batch potentially reuslts in us unhooking from a document. In that case we want to be able to do that without having to jump back to the UI thread to do so. Right now I'm not actually marking anything as being foreground affinitized as much as explicitly marking the things that can be called on any thread.
In the project system refactoring to support free-threaded initialization, I lost this call which was causing removing and readding files to do bad things. This fixes it. The fix is more complicated than just adding the call back in, because we now allow document removal to happen on a background thread which we didn't allow before, and so bit of work that must happen on the UI thread must now be deferred until a later cleanup point. Fixes dotnet#33080.
This change enforces nullable validation on tuple type parameters, assuming a custom defined tuple, inside of method bodies. closes dotnet#33303
We never actually had any tests that tested Code Model and our project system shims at the same time. To fix this required pulling RoslynVisualStudioWorkspace.GetFileCodeModel down to VisualStudioWorkspaceImpl, and fixing up some mocks we have to be (every so) slightly more accurate.
Most nullability checking of tuple values should occur during the nullable walking phase. This is because the test relies on the inference of the values, not the explicit types in the code. The only time we need to validate tuple nullability constarints during initial binding is when we're binding a named type.
WpfSharedTestData had two static members: Instance and TestSerializationGateName. TestSerializationGateName is the name of a system-wide Semaphore that was used to execute WpfFacts one at time. The intent is this was a GUID so it wouldn't actually be shared. Unfortunately, the Instance member is initialized first; and the non-static Semaphore field is initialized with the still uninitialized TestSerializationGateName. This means our Semaphore would always be named with a GUID of all-zeros, causing us to share the semaphore between all running xUnit processes. This was terribly bad for two reasons: 1. It kills test performance. We run tests in parallel in separate processes to ensure isolation, but this sharing of the semaphore meant that all of those processes are only running one test at a time, defeating all running of tests in parallel. 2. If one test process crashes, the Semaphore is never freed, meaning all your other test processes will deadlock and never complete. It's unclear why this code is using a Semaphore, but since we have no need to share the Semaphore between processes, we can use a SemaphoreSlim. This also has the added benefit of properly supporting a WaitAsync that isn't implemented by launching off a Thread just to wait for the system semaphore.
It was marked as [Serializable] but the type never would have been because it holds onto non-Serializable types. We also were never using the serialization abilities: it seems in the end we always just used WpfTestSharedData.Instance regardless.
…le-lifetime Call ProjectCodeModel.OnSourceFileRemoved when we remove files
Integration tests require active focus, so we set it there before SendInput calls and allow it to stay there.
…#33400) * when PreferProvisionalTab option is added, work is done only in OpenDocument, but not in NavigateTo making the option useless in some cases since NavigateTo makes focus to move to provisional tab right after OpenDocument call which make sure provisional tab to not activated. fix is following editor team's recommendation from https://devdiv.visualstudio.com/DevDiv/_workitems/edit/402396 * address feedback to wrap whole code under scope
Do not apply Fix All operations to generated code
Merge dev16.0 to master
SendInput using scan codes when available
…dotnet#33400)" This reverts commit 2750f63.
…iles-changing Subscribe to and process rule set file changes
Fix up all the test project launchSettings.json to allow F5 again
…ntation_broken Update the FindImplementationsForInterfaceMember
Revert "set no activation context on provisional tab when navigate to"
Merge dev16.0 to master
Cache visited assemblies to improve object browser startup
Add a hang mitigating timeout to WaitForBuildToFinish
AlekseyTs
added
Area-Compilers
Feature - Default Interface Impl
Default Interface Implementation
labels
Feb 22, 2019
RikkiGibson
approved these changes
Feb 22, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.