Stream: t-compiler/wg-rls-2.0

Topic: vscode-ext


csmoe (Feb 24 2019 at 17:44, on Zulip):

@matklad have you tried vim-ext for vscode? analyzer seems incompatible with vim-ext

matklad (Feb 24 2019 at 17:45, on Zulip):

No, I haven't tried that. Might be a good idea to run it with RUST_LOG=debug and see what's in the log

matklad (Feb 24 2019 at 17:46, on Zulip):

A common reason for incompatibility is that the client fails to send an initialized message.

csmoe (Feb 24 2019 at 17:46, on Zulip):

@matklad okay, I'll try to debug it.

csmoe (Feb 24 2019 at 17:47, on Zulip):

anyway, while searching for "vim", I got: https://github.com/rust-analyzer/rust-analyzer/search?q=vim&unscoped_q=vim

csmoe (Feb 24 2019 at 17:47, on Zulip):

solution seems already there :slight_smile:

matklad (Feb 24 2019 at 17:48, on Zulip):

ahh, sorry, I thought that's about VIM the editor, not about vim the vscode plugin

matklad (Feb 24 2019 at 17:49, on Zulip):

yeah, that's a bad issue without a clear path to fix it : )

vipentti (Feb 24 2019 at 17:52, on Zulip):

Fixing enhancedTyping with VIM would require vscode fix I believe, https://github.com/Microsoft/vscode/issues/13441

matklad (Feb 24 2019 at 17:53, on Zulip):

This also should really be a part of the protocol, instead of the horrid hack we currently use :)

csmoe (Feb 27 2019 at 09:34, on Zulip):

(I changed the name of this stream as QA for the vscode-extension)
@matklad not sure whether vscode itself is the one to blame. how to stop the rust-analyzer poping up this error message? it's a bit annoying.

csmoe (Feb 27 2019 at 09:35, on Zulip):

pasted image

vipentti (Feb 27 2019 at 09:37, on Zulip):

I think it's related to https://github.com/rust-analyzer/rust-analyzer/blob/4248b39993e2446c66f732ae9e45fb2f564099f5/crates/ra_lsp_server/src/main_loop.rs#L418-L423 , we could consider not reporting content modified error to the client

matklad (Feb 27 2019 at 09:37, on Zulip):

that's https://github.com/Microsoft/vscode-languageserver-node/issues/457.

matklad (Feb 27 2019 at 09:38, on Zulip):

But yeah, I wonder if just reponding with result: null will work as we want?

vipentti (Feb 27 2019 at 09:48, on Zulip):

Is it possible to handle it in vscode client?

matklad (Feb 27 2019 at 09:49, on Zulip):

I think it's possible, but very complicated. Have you tried just returning a null result in the server? Does it blow up something?

vipentti (Feb 27 2019 at 09:52, on Zulip):

I have not, I can try in a bit to see if this can fixed easily. It would be nice since the pop-up is somewhat annoying

vipentti (Feb 27 2019 at 10:52, on Zulip):

A workaround fix for this issue in rust-analyzer#903

Jeremy Kolb (Feb 27 2019 at 13:29, on Zulip):

Not sure if it is related but codelens fails to work once that happens and you have to switch files. My guess is that the client is expecting a specific error but I haven't looked into it

vipentti (Feb 27 2019 at 13:35, on Zulip):

Have you tried it now, after rust-analyzer#903 was merged?

csmoe (Feb 27 2019 at 13:49, on Zulip):

@vipentti not yet but soon, cargo install-code ing
feels good.

csmoe (Mar 01 2019 at 08:57, on Zulip):

@matklad ra_lsp failed to figure out the implementations here:
pasted image

Florian Diebold (Mar 01 2019 at 11:06, on Zulip):

Might be related to the generic param defaults :thinking:

Jeremy Kolb (Mar 01 2019 at 12:55, on Zulip):

Yeah we don't handle generics in this case.

Jeremy Kolb (Mar 01 2019 at 12:55, on Zulip):

I would assume that 'go to implementation' in vscode also fails on the above

Jeremy Kolb (Mar 01 2019 at 12:56, on Zulip):

since the codelens uses that internally

Jeremy Kolb (Mar 01 2019 at 14:52, on Zulip):

@csmoe where can i find that snippet?

Jeremy Kolb (Mar 01 2019 at 14:53, on Zulip):

I have a simple case with those features and it seems to work

csmoe (Mar 01 2019 at 15:37, on Zulip):

@Jeremy Kolb it's from rustc codebase

Last update: Nov 19 2019 at 18:55UTC