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
Delete Roslyn's ICommandHandler interface and all support code #32623
Delete Roslyn's ICommandHandler interface and all support code #32623
Conversation
FYI to @ivanbasov, here's what all seems to be dead code in the area we were looking at. To everyone: I'm not going to be trying to merge this for 16.0 as indeed there is much testing needed and perhaps also some shims that need to be added for F# and TypeScript. This was mostly done because @ivanbasov and I were looking at a bug and got very confused once we realized that almost all of what it was doing was dead, and this confirms it. So if you want to take a peek sure go ahead, but this is on the backburner for a few weeks. |
break; | ||
|
||
// If we see a RETURN, and we're in the immediate window, we'll want to rebuild | ||
// spans after all the other command handlers have run. | ||
case VSConstants.VSStd2KCmdID.RETURN: | ||
ExecuteReturn(subjectBuffer, contentType, executeNextCommandTarget); | ||
result = NextCommandTarget.Exec(ref pguidCmdGroup, commandId, executeInformation, pvaIn, pvaOut); |
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.
The existing code here has some subtle bugs: the Execute* methods that took executeNextCommandTarget
would update result
, but the code that didn't would fail to update result and we'd always return S_OK. At this point, I'm leaving the bugs in place.
} | ||
} | ||
|
||
break; | ||
|
||
default: | ||
return base.ExecuteVisualStudio2000(ref pguidCmdGroup, commandId, executeInformation, pvaIn, pvaOut, subjectBuffer, contentType); | ||
return base.ExecuteVisualStudio2000(ref pguidCmdGroup, commandId, executeInformation, pvaIn, pvaOut); |
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.
Yes, this appears to be a bug where this would return and we'd never do the SetStateFlags below. Leaving the bug here for now.
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.
@@ -90,33 +63,11 @@ void executeNextCommandTarget() | |||
switch ((VSConstants.AppCommandCmdID)commandId) | |||
{ | |||
case VSConstants.AppCommandCmdID.BrowserBackward: | |||
ExecuteBrowserBackward(subjectBuffer, contentType, executeNextCommandTarget); | |||
ExecuteBrowserBackward(executeNextCommandTarget); |
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.
Should we add editor commanding support for these commands so you could switch to modern command handlers and get rid of this command filter altogether?
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.
I'm not even sure why we have this in the first place. I think this is wiring up back/forward mouse commands to invoke the buttons on the UI. Why that's just not handled in the shell I don't know.
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.
it would be great to start a discussion on that so we can remove this entirely.
src/VisualStudio/Core/Def/Implementation/DebuggerIntelliSense/DebuggerIntellisenseFilter.cs
Outdated
Show resolved
Hide resolved
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.
4c3a164
to
9df750a
Compare
@jasonmalinowski integration test failures look like true failures for this PR |
@sharwell, great, thanks! |
9df750a
to
d420694
Compare
d420694
to
d61705d
Compare
1d31614
to
858746b
Compare
858746b
to
50d10b8
Compare
…tation Now that TypeScript has moved to the newer editor commanding APIs, the legacy implementation is no longer needed.
The command was ultimately being made available not because our command handler said it should be, but our implementation of QueryStatus in AbtractOleCommandTarget was unilterally saying the command is available. This moves that into here.
Now that the editor has their own public version of this API, and all code has been migrated to use the new system, we can delete all of the code that was supporting the old handlers. It may be surprising that much of this code was dead, but the command handler list that was being invoked by all of this was indeed empty. The intent of this particular commit is to be a fairly mechanical change that leaves other bugs or strangeness in place. In particular, DebuggerIntelliSenseFilter had a special ExecuteVisualStudio2000 that removes the buffer's read-only flag, but in many codepaths we never set that back. In other cases, we also ignored the HRESULT that came from the next filter in the chain. These all appear to be bugs, but I won't touch them for now. There's also some remaining work happening in AbstractOleCommandTarget.Execute.cs that probably should either be moved to the core editor code (if it wasn't already), or into the command handlers of Roslyn itself.
My previous commit deleted this interface and a constructor that consumes it. But TypeScript is still MEF importing the interface just to pass it to the constructor; this adds both of those back. Once TypeScript is off of this constructor this commit can be reverted verbatim.
Now that the old code is dead, we don't need to qualify things anymore.
50d10b8
to
559f6ff
Compare
Now that the editor has their own public version of this API, and all code has been migrated to use the new system, we can delete all of the code that was supporting the old handlers. It may be surprising that much of this code was dead, but the command handler list that was being invoked by all of this was indeed empty.
Things still to do: