Skip to content
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

Setting rust-analyzer.serverPath silently hoses things up if incorrect #5091

Closed
buzmeg opened this issue Jun 27, 2020 · 1 comment · Fixed by #5185
Closed

Setting rust-analyzer.serverPath silently hoses things up if incorrect #5091

buzmeg opened this issue Jun 27, 2020 · 1 comment · Fixed by #5185

Comments

@buzmeg
Copy link

buzmeg commented Jun 27, 2020

If you have serverPath set incorrectly, rust-analyzer/VSCode gives no indication of the fact that it can't find the server. It just quietly fails.

I discovered this when I attempted to use rust-analyzer on my local machine instead of on a remote machine like I had been doing.

I believe that #5045 is a special case of this, so I have closed that bug in favor of this one.

Thanks.

@Veetaha
Copy link
Contributor

Veetaha commented Jun 28, 2020

This is very weird. When testing #4993 I clearly saw an error notification pop up (even made a screenshot of one).
But right now, when trying to synthesize an error there is no popup notification. I remember even hitting such a case where there was no notification about the activation failure before #4993, but for some reason when writing that PR everything worked as intended so I just didn't elaborate on that.
The 100% solution would be just forcing an error notification, but it would be better to find out what is going on (microsoft/vscode#101242)...

@bors bors bot closed this as completed in 57ed622 Jul 2, 2020
matklad pushed a commit to matklad/vscode-rust that referenced this issue Jul 13, 2020
5089: Disable auto-complete on comments r=matklad a=BGluth

Resolves #4907 by disabling any auto-completion on comments.

As flodiebold [pointed out](rust-lang/rust-analyzer#4907 (comment)), in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.

The implementation involves adding a new field `is_comment` to `CompletionContext` and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.

Finally, the three tests I added should I think ideally not filter results by `CompletionKind::Keyword`, but if I want to get unfiltered results, I need access to a non-public function [get_all_completion_items](https://github.com/rust-analyzer/rust-analyzer/blob/9a4d02faf9c47f401b8756c3f7fcab2198f5f9cd/crates/ra_ide/src/completion/test_utils.rs#L32-L39) which I don't know if I should make public just for this.



5161: SSR: Add initial support for placeholder constraints r=matklad a=davidlattimore



5184: Always install required nightly extension if current one is not nightly r=matklad a=Veetaha

This is weird, but having switched back to stable by uninstalling the extension appears that vscode doesn't destroy the `PersistentState` and thus changing to `nightly` channel doesn't work because the last check for nightly extension was less than 1 hour ago. The simple solution is to skip this check if we know that the current extension version is not nightly.

5185: Force showing extension activation error pop-up notification r=matklad a=Veetaha

Fixes rust-lang/rust-analyzer#5091

5186: fix: correct pd/ppd/tfn/tmod completion doc r=matklad a=fannheyward

https://github.com/rust-analyzer/rust-analyzer/blob/a33eefa3b26000b3018e6bb873f18dbe15ab4ab7/crates/ra_ide/src/completion/complete_snippet.rs#L23-L24

Co-authored-by: BGluth <[email protected]>
Co-authored-by: David Lattimore <[email protected]>
Co-authored-by: Veetaha <[email protected]>
Co-authored-by: Heyward Fann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants