-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Remove descendent node tracking from SyntaxEditor #67314
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
Conversation
b41b5f1 to
0985fc2
Compare
| destinationEditor.SemanticModel.Compilation, | ||
| node, | ||
| node.GetCurrentNode(newDestination), | ||
| node.GetAnnotatedNodes(s_destinationNodeAnnotation).FirstOrDefault(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was the bad line. They were basically trying to find this totally fresh node in the current root. but that totally fresh node was already morphed into a different node when teh replacement happened. Trivial fix is to just use our own annotation to track it, instead of the editor tracking all nodes.
hrmm... i would think so. otehrwise i'm not sure how we would find the node after edits... teh tracking of change.OriginalNode seems very important... |
mavasani
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
Revert "Remove descendent node tracking from SyntaxEditor #67314" from 17.6
This is showing up as extremely expensive in code action application, as some code actions track the whole tree, which adds hundreds of thousands of nodes to a CWT with annotations.
We're reverting back to the original design/impl here as it's extremely trivial and has almost no perf overhead. The single case that needed this behavior is much better served by a dedicated 2-line fix within the feature itself.