Skip to content
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

Conversation

AlekseyTs
Copy link
Contributor

No description provided.

mavasani and others added 30 commits December 10, 2018 16:02
…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
sharwell and others added 21 commits February 20, 2019 21:15
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
SendInput using scan codes when available
…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"
Cache visited assemblies to improve object browser startup
Add a hang mitigating timeout to WaitForBuildToFinish
@AlekseyTs AlekseyTs requested review from a team as code owners February 22, 2019 18:34
@AlekseyTs AlekseyTs merged commit 77b0357 into dotnet:features/DefaultInterfaceImplementation Feb 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.