Skip to content

Conversation

@AlekseyTs
Copy link
Contributor

No description provided.

jjonescz and others added 30 commits July 8, 2025 09:16
* Fix debugging of build tasks

* Split into a new target
* Fix ref safety of user-defined increment operators

* Update after merge

* Improve code and tests
There's two issues here:

1. Some tests of the VS layer didn't have the telemetry service in the
   first place.
2. There was now a circularity between the VisualStudioWorkspace and
   VisualStudioWorkspaceTelemetryService, so a Lazy has been added.
All subscribers are working in thread-safe manners (they either take
locks to clear caches, or use existing batching/threading primitives to
queue new work).
Subscribers were already thread safe. I've also removed the IMPORTANT
warning since it seems quite stale -- this is already in a delayed queue
so it's not really clear what it meant.
I'm unable to figure out what the intent was here -- it clears the list
but only on a SolutionChanged event, which is the type of event
raised if multiple projects are modified at once in a single workspace
change -- any other type of event would have a more specific kind.
I could imagine the intent might have been for solution close, but
then I can imagine scenarios where the user might have pasted a stack
and now needs to switch the solution to navigate from the stack.

Since this likely never ran, I'm just deleting it.
If the user expands a node in a CPS project wanting to look at the
diagnostics under an analyzer, but we haven't been told about that
analyzer let, we stick a WorkspaceChanged handler there to find it once
it comes back. We were hopping to the UI thread to see if the
CanonicalName of the item could have changed, but that's not really
going to happen ever for these items, so we can just grab it once
during creation and be done with it.
This looks to be safely callable from any thread.
…elComputation (dotnet#79292)

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2428510

This was previously addressed by adding a Task.Yield to the TransformModelAsync execution, instead this moves that stack size mitigation to the exception handling process. Per dotnet#26567, the vast majority of stack size during stack unwinding is due to the unwinding process itself.
* wip

* wip

* wip

* fix tests

* wip

* remove unused code

* update test impl

* update option test

* add cancel method

* some cleanup

* call CommitAsync in tests instead

* fix some comments and naming

* rename commit to make it more clear it's an async operation

* feedback

* feedback

* fix integration test
…et#78984)

Part of dotnet/razor#11831

Razor side that completes the fix is
dotnet/razor#11952

I am _well_ out of my depth with rename, and have commented on a couple
of spots that might be contentious, or are otherwise worth noting.
@AlekseyTs AlekseyTs enabled auto-merge July 21, 2025 11:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.