Unable to get quick fixes in problems view to work

[Gama11]

Issue Type: Bug

VS Code version: Code - Insiders 1.26.0-insider (26e5a55, 2018-07-20T05:18:39.569Z)
OS version: Windows_NT x64 10.0.17134

After trying to support #52627 in the Haxe language server didn't work as expected, I tried with a simple VSCode extension, but I didn't have much luck here either. I'm setting the diagnostics property of the CodeAction as required according to #52627 (comment) - is there anything else I'm missing?

import * as vscode from "vscode";

export function activate(context: vscode.ExtensionContext) {
	var diagnostics = vscode.languages.createDiagnosticCollection("foo");
	vscode.window.onDidChangeActiveTextEditor(editor => {
		if (editor != null) {
			var diagnostic = new vscode.Diagnostic(new vscode.Range(0, 0, 1, 0), "Message");
			diagnostics.set(editor.document.uri, [diagnostic]);
		}
	});
	vscode.languages.registerCodeActionsProvider('plaintext', {
		provideCodeActions(document) {
			var action = new vscode.CodeAction("Fix");
			action.diagnostics = diagnostics.get(document.uri);
			console.log(action);
			return [action];
		}
	});
}

[jrieken]

This is fishy diagnostics.get(document.uri) because Uri-objects aren't comparable by object id because new instances are created all the time. Use document.uri.toString() for something that works as key.

[vscodebot]

We have a great developer community over on slack where extension authors help each other. This is a great place for you to ask questions and find support.

Happy Coding!

[Gama11]

Hm.. get() expects a Uri instance, so a toString() there would result in a compiler error. Why is toString() important, because of the normalization it does?

Anyway, it's actually not the diagnostics.get() call that is failing. If you dig down into the console.log() in the next line, you can see that the returned CodeAction does have the correct diagnostic attached to it:

---

I also thought that the example may be too isolated, and that an edit may be required for it to work. However, even with:

action.edit = new WorkspaceEdit();
action.edit.replace(document.uri, new vscode.Range(0, 0, 1, 0), "Foo");

...the quick fix still can't be triggered from the problems view:

[jrieken]

Sorry, I missed that this is our DiagnosticCollection and not a map you have created (internally we call toString then).

[jrieken]

Ok, I know now. The context menu filters for code actions of the quickFix-kind. So adding action.kind = vscode.CodeActionKind.QuickFix; to your sample will make them show.

[jrieken]

@mjbvz I think we should print a message when we drop code actions on the client because of filtering/request constraints

[Gama11]

Oh, interesting. I had assumed that CodeActionKind.QuickFix would be the default, so I didn't bother setting it explicitly. Especially considering Empty doesn't exist in the LSP types and QuickFix is the first value in CodeActionKind there:

https://github.com/Microsoft/vscode-languageserver-node/blob/5f9c993ff38f5c369949aeb359b3e9b178172dbc/types/src/main.ts#L1738-L1746

So I guess the default kind is actually Empty...? Perhaps the CodeAction.kind docs could clarify that.

[mjbvz]

@Gama11 Yes the default for quick fixes is empty. This is because the editor lightbulb isn't tied to quick fixes specifically but also will show up if there are refactorings and other action types available. For quick fixes in the problems view however, we do request that extensions only provide quick fixes and will filter out anything that isn't marked as such

@jrieken I can add some debug logging here but it will be noisy since many code action providers return commands or return CodeAction but fail to set the codeActionKind. Worth pushing extension developers to update their code? Maybe don't log when someone is returning commands?

[jrieken]

Worth pushing extension developers to update their code? Maybe don't log when someone is returning commands?

Yeah, only when a code action is returned. We can also use the log service for this