VSCode completion: wrong suggestions after typing a keyword

[obiwanus]

Only tested in VSCode, so may be a problem with it or with its rust-analyzer extension. Please point me to the right place to report this issue to if so.

Whenever I type a keyword like unsafe or impl or struct it suggests the thread_local! snippet, which is very annoying.

Here, I've recorded my screen demonstrating the issue: https://www.youtube.com/watch?v=z6Y7kRvu6og

Note: when I type the keyword if inside a function, it doesn't suggest anything. But if it's typed outside a function (i.e. where it's not supposed to be) we see the same error as with other keywords. Maybe that helps.

Thanks.

[mcrakhman]

Will investigate that

[mcrakhman]

This problem exists only in VSCode.

When I type impl at the top level (i.e. module level) the only completion items we produce are the one made by complete_item_snippet (several snippets including for eprintln) and complete_macro_in_item_position, we produce them no matter what is the start of the string.

Vscode itself does the filtering (fuzzy search?) of all the items we produce. When it sees certain keywords it starts the fuzzy search from the next symbol after the keyword (in your case it is " "). This part I actually don't understand, because it does that for example with enum, struct and impl, but at the same time it doesn't do it with trait, mod, fn etc. Also if this keyword is recognized as completion item it behaves correctly.

Anyways the only thing in our completion items containing space is "thread_local! {…}", that's why when I type impl and then " " it filters only thread_local, try typing different symbol after for example impl, you will see different items like include etc.

The same happens with unsafe as we don't provide any completion to it.

So probably if we would add the keywords unsafe, enum, struct etc as completion items the problem should go away. Should we do that @matklad? Or there was a specific reason why we don't provide them as completion items (it looks like IntelliJ does that). Thanks!

[flodiebold]

Hmm I'm pretty sure I've seen this in Emacs as well 🤔

I think we should provide all keywords as completions, it's just not implemented yet.

But we also shouldn't be providing these macro completions in a position where they aren't valid.

[mcrakhman]

Hmm I'm pretty sure I've seen this in Emacs as well 🤔

I think we should provide all keywords as completions, it's just not implemented yet.

But we also shouldn't be providing these macro completions in a position where they aren't valid.

I thought that initial design decision was to provide everything that's possible and leave IDE to do fuzzy search on top of that. But it also seems reasonable to do filtering on our own, so that we would get same behaviour on different IDE's

[flodiebold]

I thought that initial design decision was to provide everything that's possible and leave IDE to do fuzzy search on top of that

But thread_local! isn't possible there, is it? I mean, I don't think the Rust grammar even allows macro calls after unsafe. It is in theory possible to have a macro call after impl, but I think we should make an effort to avoid giving macro completions that don't make sense even there.

The fact that it proposes the thread_local one directly after the keyword might be a VSCode thing, though, you're right. That seems very annoying. In Emacs, I only get the completion after a space, and together with lots of other completions.

[mcrakhman]

@flodiebold Does it make sense to have two PRs? One will introduce keywords like enum etc, and the other one will have more fine grained control over what we provide in completion with respect to macro.

[flodiebold]

Yes, these are completely separate problems.

[mcrakhman]

Ok, I will start with adding keywords

[matklad]

Seems to work ok on master,